Closed Bug 1390803 Opened 3 years ago Closed 2 years ago

Add "GlobalSign Root CA - R6" root certificate

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: koichi.sugimoto, Assigned: wthayer)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.39, FF 63. EV-enabled in FF 64)

Attachments

(7 files, 2 obsolete files)

31.04 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
157.88 KB, application/pdf
Details
36.49 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
516.00 KB, application/pdf
Details
2.66 MB, application/pdf
Details
2.22 MB, application/pdf
Details
510.50 KB, application/pdf
Details
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

GlobalSign created an new root CA certificate with RSA4096 key.
The new root certificate can be downloaded via our repository: 
https://secure.globalsign.net/cacert/root-r6.crt

https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates


Actual results:

The certificate is not included in NSS, Firefox, etc.



Expected results:

The root certificate should be included into NSS.
The target security services are:
SSL (including EV), Time stamping, S/MIME, Code signing etc.
Koichi, Please provide the information listed here:
https://wiki.mozilla.org/CA/Information_Checklist
Assignee: kwilson → awu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying] - Need BR Self Assessment
Attached as part of GlobalSign Root R6 Certificate inclusion to Mozilla products.
I have just uploaded our company checklist according to Mozilla root inclusion policy process. Our BR Self-Assessment was recently submitted to/approved by Kathleen Wilson on 12/19/2017. Let me know if you have any questions!
(In reply to Julie Olson from comment #3)
> I have just uploaded our company checklist according to Mozilla root
> inclusion policy process. Our BR Self-Assessment was recently submitted
> to/approved by Kathleen Wilson on 12/19/2017. Let me know if you have any
> questions!

Oh, I thought the BR Self-Assessment that you emailed to me was in regards to the CA Communication.

Please also attach your BR Self-Assessment to this bug, as it is part of our root inclusion/update process.

Thanks.
GlobalSign BR Self-Assessment as part of Root R6 inclusion process
(In reply to Julie Olson from comment #5)
> Created attachment 8941595 [details]
> CA's BR Self Assessment_GlobalSign.xlsx
> 
> GlobalSign BR Self-Assessment as part of Root R6 inclusion process

Thanks! 

I will update this bug when I do the review as per step 2 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Note that it may take me a few weeks to get to this. I apologize in advance for the delay.
Assignee: awu → kwilson
Whiteboard: [ca-verifying] - Need BR Self Assessment → [ca-verifying] - BR Self Assessment Provided
Hello Kathleen, I was hoping you could provide a status update on your review of our root inclusion request?

Thanks,
Julie.
(In reply to Julie Olson from comment #7)
> Hello Kathleen, I was hoping you could provide a status update on your
> review of our root inclusion request?
> 
> Thanks,
> Julie.

I'm currently 4 months behind on reviewing CA updates to this type of bug.
Hi Kathleen,

We realized we accidentally forgot to include one admin CA to the R6 hierarchy. I'm uploading an updated checklist with the correct hierarchy, plus updated POC details.

The CA is publicly disclosed in CCADB, and will be depreciated next month.
Attachment #8941556 - Attachment is obsolete: true
This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.
Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - BR Self Assessment Provided → [ca-cps-review] - KW 2018-03-27
Our CP/CPS has been updated as of today, 4/3/2018. New URLs are:

CP: https://downloads.globalsign.com/acton/attachment/2674/f-0a61/1/-/-/-/-/GlobalSign_CP_v5_7_RELEASED.pdf
CPS: https://downloads.globalsign.com/acton/attachment/2674/f-0a60/1/-/-/-/-/GlobalSign_CA_CPS_v8_7_RELEASED.pdf

In addition, I'm uploading a new copy (v6) of our checklist, with updated URLs and section references to the new documents.
Attachment #8959151 - Attachment is obsolete: true
I've begun reviewing this request and have a few questions:
* can you provide a copy of GlobalSign's 2015-2016 BR audit statement listing this root?
* are GlobalSign's CAA issuer domains listed in the CP or CPS? If not, would you like to add them before this goes to public discussion? This is a requirement of BR section 2.2.
* the CPS change log for version 8.7 says that it now specifies that GlobalSign no longer generates keys for SSL certificates. Can you point me to the language that was added to the CPS?
* CPS section 3.3.1 references re-verification of re-key requests every 5 years rather than every 825 days. Do you want to fix this before this goes to public discussion?
Flags: needinfo?(julie.olson)
I've completed my initial review and have documented the following comments:

==Good==
While this root was created in 2014, it does not appear to have been used beyond issuing test certificates.
The CP and CPS state “GlobalSign CA expressly forbids the use of chaining services for MITM (Man in the Middle) SSL/TLS deep packet inspection. “

==Meh==
The 2016-2017 BR audit contains two qualifications. One is described as follows:

Management discovered a bug that allowed orders that are re-issued with modified domains within the Subject Alternative Name field of the certificate to not include the Key Usage (KU) or Extended Key Usage (EKU) extensions. This occurred between August29 , 2016 and September 19, 2016. Management noted 68 Certificates were affected, 4 of these are extended validation certificates and 64 are organization validation certificates. Management was not able to revoke all certificates within 24 hours, due to customer requirements.

GlobalSign disclosed this problem at the time [1]. The other qualification in the report is related to data backups.
GlobalSign was the subject of 3 misissuance bugs in 2017 [2], but all have been resolved.
CP and CPS section 3.3.1 references re-verification of re-key requests every 5 years rather than every 825 days.
The CP and CPS reference “IntranetSSL” certificates in multiple places, and section 3.2.4 of both documents references a BR sunset that has long since passed but in so doing implies that these certificates are still being issued. Suggest updating/clarifying this in the CPS.
CPS section 3.2.7 indicates that GlobalSign uses “any other method” for IP address validation. 
CPS section 3.2.7 indicates that GlobalSign still uses the soon-to-be deprecated methods 1 and 5 for domain validation.

==Bad==
Section 6.2.10 of the CP and CPS states “As of March 1, 2018, GlobalSign does not generate private keys for SSL certificates.“ Implying that prior to that date, GlobalSign did this in violation of Mozilla’s Forbidden Practice [3]


I will proceed with this request once a GlobalSign representative responds to my questions in comment #13.

[1] https://cabforum.org/pipermail/public/2016-October/008511.html
[2] https://wiki.mozilla.org/CA/Closed_Incidents
[3] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
Hi Wayne,

I have answered all your questions in-line below; please let me know if you have any follow-up questions.

(In reply to Wayne Thayer [:wayne] from comment #13)
> I've begun reviewing this request and have a few questions:
> * can you provide a copy of GlobalSign's 2015-2016 BR audit statement
> listing this root?
Yes, I have attached it to this bug.

> * are GlobalSign's CAA issuer domains listed in the CP or CPS? If not, would
> you like to add them before this goes to public discussion? This is a
> requirement of BR section 2.2.
Please refer to Section 4.2.1: "GlobalSign validates each server FQDN in publicly trusted SSL certificates against the domain's CAA records. If a CAA record exists that does not list globalsign.com as an authorized CA, GlobalSign will not issue the certificate." GlobalSign's CAA issuer domain is "globalsign.com." We are in the final stages of publishing a new version of our CP/CPS and have made this more clear in the documentation. I will update the link to our new CP/CPS when it's published.

> * the CPS change log for version 8.7 says that it now specifies that
> GlobalSign no longer generates keys for SSL certificates. Can you point me
> to the language that was added to the CPS?
Please refer to Section 6.2.10: "As of March 1, 2018, GlobalSign does not generate private keys for SSL certificates." We are in the final stages of publishing a new version of our CP/CPS and have made this statement more clear in the documentation. I will update the link to our new CP/CPS when it's published.

> * CPS section 3.3.1 references re-verification of re-key requests every 5
> years rather than every 825 days. Do you want to fix this before this goes
> to public discussion?
Yes please! We are in the final stages of publishing a new version of our CP/CPS and have corrected this statement in the documentation. I will update the link to our new CP/CPS when it's published.

(In reply to Wayne Thayer [:wayne] from comment #14)
> I've completed my initial review and have documented the following comments:
> 
> ==Good==
> While this root was created in 2014, it does not appear to have been used
> beyond issuing test certificates.
> The CP and CPS state “GlobalSign CA expressly forbids the use of chaining
> services for MITM (Man in the Middle) SSL/TLS deep packet inspection. “
> 
> ==Meh==
> The 2016-2017 BR audit contains two qualifications. One is described as
> follows:
> 
> Management discovered a bug that allowed orders that are re-issued with
> modified domains within the Subject Alternative Name field of the
> certificate to not include the Key Usage (KU) or Extended Key Usage (EKU)
> extensions. This occurred between August29 , 2016 and September 19, 2016.
> Management noted 68 Certificates were affected, 4 of these are extended
> validation certificates and 64 are organization validation certificates.
> Management was not able to revoke all certificates within 24 hours, due to
> customer requirements.
> 
> GlobalSign disclosed this problem at the time [1]. The other qualification
> in the report is related to data backups.
> GlobalSign was the subject of 3 misissuance bugs in 2017 [2], but all have
> been resolved.
> CP and CPS section 3.3.1 references re-verification of re-key requests every
> 5 years rather than every 825 days.
See above; We are in the final stages of publishing a new version of our CP/CPS and have corrected this statement in the documentation. I will update the link to our new CP/CPS when it's published.

> The CP and CPS reference “IntranetSSL” certificates in multiple places, and
> section 3.2.4 of both documents references a BR sunset that has long since
> passed but in so doing implies that these certificates are still being
> issued. Suggest updating/clarifying this in the CPS.
Noted. We are in the final stages of publishing a new version of our CP/CPS and have corrected this statement in the documentation. I will update the link to our new CP/CPS when it's published.

> CPS section 3.2.7 indicates that GlobalSign uses “any other method” for IP
> address validation. 
The only “any other method” GlobalSign uses is email/phone verification via IANA (ARIN RIPE, APNIC, LACNIC, AFRINIC) IP whois information.

> CPS section 3.2.7 indicates that GlobalSign still uses the soon-to-be
> deprecated methods 1 and 5 for domain validation.
We do not use Method 5 any longer and have removing the method in the next CP/CPS version. We still use Method 1 in some cases, and are working to put new processes in place to fully disable Method 1 by August.
> 
> ==Bad==
> Section 6.2.10 of the CP and CPS states “As of March 1, 2018, GlobalSign
> does not generate private keys for SSL certificates.“ Implying that prior to
> that date, GlobalSign did this in violation of Mozilla’s Forbidden Practice
> [3]
As part of the Self assessment we identified this deficiency, and following a discussion on the MDSP list, we ended this practice for publicly trusted SSL/TLS certificates in March 2018.
> 
> 
> I will proceed with this request once a GlobalSign representative responds
> to my questions in comment #13.
> 
> [1] https://cabforum.org/pipermail/public/2016-October/008511.html
> [2] https://wiki.mozilla.org/CA/Closed_Incidents
> [3]
> https://wiki.mozilla.org/CA/
> Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKC
> S.2312_Files
Flags: needinfo?(julie.olson)
Whiteboard: [ca-cps-review] - KW 2018-03-27 → [ca-cps-review] - Pending CPS Updates 2018-05-24
Hi Wayne,

Attached is a copy of our updated CPS v8.8. It has changes that address the deficiencies/questions you identified during your previous review of v8.7.

We are ready to proceed with the next step of the root embedding process.
Attached file GlobalSign CP v5.8.PDF
Hi Wayne,

Attached is a copy of our updated CP v5.8. It has changes that address the deficiencies/questions you identified during your previous review of v5.7.

We are ready to proceed with the next step of the root embedding process.
Julie: can you provide a BR audit report for the April 1, 2015 - March 31, 2016 period?
Hi Wayne,

The requested audit report is attached to this bug, "16 - GlobalSign - WebTrust Baseline Requirements 2015-16"

Thanks,
Julie.
Public discussion has begun: https://groups.google.com/d/msg/mozilla.dev.security.policy/gMnbLOpggRw/X-jWH2SsBgAJ
Whiteboard: [ca-cps-review] - Pending CPS Updates 2018-05-24 → [ca-in-discussion] - ends no sooner than 19-July-2018
(In reply to Julie Olson from comment #20)
> Hi Wayne,
> 
> The requested audit report is attached to this bug, "16 - GlobalSign -
> WebTrust Baseline Requirements 2015-16"
> 
> Thanks,
> Julie.

Julie: Since this root was created in December 2014, I should have also asked for GlobalSign's 2014-2015 BR audit report. Can you attach a copy of that as well?
Flags: needinfo?(julie.olson)
Hi Wayne,

Attached is our audit report from 2014-2015. Let me know if you need anything else.
Flags: needinfo?(julie.olson)
This request has completed its 3-week public comment period with no comments received.

I have posted my intention to approve this root inclusion request (https://groups.google.com/d/msg/mozilla.dev.security.policy/xnzoZvZc4FM/RcqmOP4CCAAJ).

For reference, here is the information posted to begin the public comment period:

This request is for inclusion of the GlobalSign Root CA - R6 as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1390803 This is an RSA-4096 / SHA-384 root that GlobalSign states “…will replace older, expiring roots that have smaller key sizes in the future.”

* BR Self-Assessment: https://bugzilla.mozilla.org/attachment.cgi?id=8941595

* Summary of Information Gathered and Verified: https://bug1390803.bmoattachments.org/attachment.cgi?id=8962928

* Root Certificate Download URL: http://secure.globalsign.com/cacert/root-r6.crt

CP/CPS:
** CP: https://downloads.globalsign.com/acton/attachment/2674/f-0b47/1/-/-/-/-/GlobalSign_CP_v5.8.pdf
** CPS: https://downloads.globalsign.com/acton/attachment/2674/f-0b46/1/-/-/-/-/GlobalSign_CA_CPS_v8_8_RELEASED.pdf

* This request is to turn on the Websites and Email trust bits. EV treatment is requested.
** EV Policy OID: 2.23.140.1.1

Test Websites:
** https://valid.r6.roots.globalsign.com/
** https://revoked.r6.roots.globalsign.com/
** https://expired.r6.roots.globalsign.com/

* CRL URL: http://crl.globalsign.com/root-r6.crl

* OCSP URL: http://ocsp2.globalsign.com/rootr6

Audit: Annual audits are performed by BDO and Ernst & Young according to the WebTrust for CA, BR, and EV audit criteria.
* WebTrust: https://cert.webtrust.org/SealFile?seal=2287&file=pdf

* BR:
** April 1, 2016 - March 31, 2016: https://bug1390803.bmoattachments.org/attachment.cgi?id=8980269 (EY - clean)
** April 1, 2016 - March 31, 2017: https://downloads.globalsign.com/acton/attachment/2674/f-08b8/1/-/-/-/-/GlobalSign-WTBR-Indp-Accountant-Report-and-Mgmt-Assertion-FINAL-2017.pdf (BDO - qualified)
** April 1, 2017 - September 18, 2017: https://downloads.globalsign.com/acton/attachment/2674/f-0960/1/-/-/-/-/GlobalSign-WTEY-Indp-Assurance-Report-FINAL-2017.pdf (EY - clean)

* EV: https://cert.webtrust.org/SealFile?seal=2288&file=pdf (BDO - clean)

I’ve reviewed the CP and CPS, BR Self Assessment, and related information for the GlobalSign Root CA - R6 inclusion request that is being tracked in this bug and have the following comments:

==Good==
* While this root was created in 2014, it does not appear to have been used beyond issuing test certificates.
* The CP and CPS state “GlobalSign CA expressly forbids the use of chaining services for MITM (Man in the Middle) SSL/TLS deep packet inspection.“
* I found GlobalSign’s CP and CPS well structured and easy to understand (despite the fact that some sections, such as 3.2.2.4 and 3.2.2.5 fail to align with the BRs).
* CPS section 3.2.8 documents email address validation methods in compliance with the new 2.6 version of the Mozilla root store policy

==Meh==
* The 2016-2017 BR audit contains two qualifications. One is described as follows:

Management discovered a bug that allowed orders that are re-issued with modified domains within the Subject Alternative Name field of the certificate to not include the Key Usage (KU) or Extended Key Usage (EKU) extensions. This occurred between August 29 , 2016 and September 19, 2016. Management noted 68 Certificates were affected, 4 of these are extended validation certificates and 64 are organization validation certificates. Management was not able to revoke all certificates within 24 hours, due to customer requirements.

GlobalSign disclosed this problem at the time [1]. The other qualification in the report is related to data backups. GlobalSign had another BR audit conducted later in 2017, resulting in a clean report.
* GlobalSign was the subject of 4 misissuance bugs in 2017, as follows. All have been resolved and this root was not involved in any of them.
** Bug 1353833 - GlobalSign: Incapsula issued a certificate for non-existing domain (testslsslfeb20.me)
** Bug 1390997 - GlobalSign: Non-BR-Compliant Certificate Issuance - metadata-only subject fields
** Bug 1393555 - GlobalSign: Non-BR-Compliant Certificate Issuance -- double-dots in dnsName
** Bug 1393557 - GlobalSign: Non-BR-Compliant Certificate Issuance -- RSA key smaller than 2048 bits
* Minor CP and CPS issues were identified, noted in the bug, and fixed by GlobalSign in the current versions.
* CPS section 3.2.7 indicates that GlobalSign uses “any other method” for IP address validation. GlobalSign responded as follows In the bug: The only “any other method” GlobalSign uses is email/phone verification via IANA (ARIN RIPE, APNIC, LACNIC, AFRINIC) IP whois information.
* CPS section 3.2.7 indicates that GlobalSign still uses the soon-to-be deprecated method 1 for domain validation. GlobalSign responded as follows in the bug: We still use Method 1 in some cases, and are working to put new processes in place to fully disable Method 1 by August.
* Earlier this year, there was a discussion related to forward-dating the notBefore date in a certificate [2] that is valid for 3 years. This was determined not to be a policy violation.

==Bad==
* CA generation of SSL key pairs is a Forbidden Practice [3]. Sections 6.2.10 of the CP and CPS state “As of March 1, 2018, GlobalSign does not generate private keys for SSL certificates.“ In the submission of this root, they stated "GlobalSign currently distributes private keys in PKCS#12 Files according to our CP/CPS 6.2. We are phasing out this practice, and will cease distributing private keys for SSL certificates in this fashion by the end of March 2018."
Whiteboard: [ca-in-discussion] - ends no sooner than 19-July-2018 → [ca-pending-approval]
As per the summary in Comment #24, and on behalf of Mozilla I approve this request from GlobalSign to include the following root certificate:

** 'GlobalSign Root CA - R6' (Email, Websites), enable EV

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: [ca-pending-approval] → [ca-approved] - Pending NSS and PSM code changes
Depends on: 1478476
Depends on: 1478480
I have filed bug #1478476 against NSS and bug #1478480 against PSM for the actual changes.
Whiteboard: [ca-approved] - Pending NSS and PSM code changes → [ca-approved] - In NSS 3.39, FF 63 -- Pending PSM code changes
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
QA Contact: kwilson
Resolution: --- → FIXED
Whiteboard: [ca-approved] - In NSS 3.39, FF 63 -- Pending PSM code changes → [ca-approved] - In NSS 3.39, FF 63. EV-enabled in FF 64

Wayne, Kathleen:

Apologies that this was missed. This only came to light when looking at intermediates issued after 2019-01-01 that were cross-signs of existing roots (i.e. those taking advantage of Section 5.3 of Mozilla Root Store Policy, v2.6.1 ).

It was looking at the following two cross-signs that I discovered that the Subject of this CA does not, nor did it when created, comply with the Baseline Requirements:

When running this Root through certlint, x509lint, or zlint, you consistently see the error. e.g. https://crt.sh/?id=19392276&opt=zlint,x509lint,cablint

I'm raising this on this bug, rather than filing a new incident, because it's unclear whether this bug was meant to be acceptance of that non-compliance, and whether the acceptance of that non-compliance permits further misissuance, until the root is retired.

I don't see any discussion here about that, so was not sure if it happened off-bug.

Flags: needinfo?(wthayer)

Ryan,
Is you concern with the Root, R6 or the Cross Certificates?

The cross-certificates are newly issued certificates, and thus the non-conforming ones.

The Baseline Requirements does not distinguish intermediate certificates from cross-signs, nor has it ever. This topic was raised in the past (e.g. when discussing the requirement in Ballot 199, which introduced the requirement for the Country field), so is not new.

I flagged it on this because it's unclear whether the inclusion of this Root should be seen as acceptance of the cross-signs being permitted by Mozilla, despite violating the BRs, or whether the inclusion of this Root (created under a pre-Ballot 199 version of the BRs) was simply that, and thus the issuance of the cross-signs an incident.

Wayne - what's your view on this topic? Does the inclusion of a root also permit cross certificates to be made to that root to facilitate it's use while the root embedding percentage increases to acceptable levels?

(In reply to douglas.beattie from comment #30)

Wayne - what's your view on this topic? Does the inclusion of a root also permit cross certificates to be made to that root to facilitate it's use while the root embedding percentage increases to acceptable levels?

There is nothing about including a root that implicitly grants a CA permission to violate the BRs, and per the discussion on the CAB Forum SCWG list [1], these are subordinate CA certificates that were issued in violation of the then-current BRs. The fact that no one raised this as a potential concern during the inclusion process does not excuse it.

This does provide a great example of the risk of accepting inclusion requests for older roots that don't meet current standards - both to the CA and to Mozilla when the CA asks for special treatment.

[1] https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html

Flags: needinfo?(wthayer)

While there was a delay in getting R6 included in NSS, I'm not sure that would help in general. The following roots don't have C in them, which precludes us from issuing cross certificates to any of them:
R3: issued 3/18/2009
R5: Issued 11/13/2012
R6: Issued 12/9/2014

This means that up until 6/8/2017 we would have been able to create cross certificates to these Roots, but are not able to do so after that date. Had we known, we would have generated them prior to this ballot's effective date, but it didn't occur to us that cross certificates to these roots would be prohibited.

Yes, Ryan did reference cross certificates in Ballot 199, but it wasn't exactly a "discussion", but more of a warning that cross certificates, when done improperly, can cause serious issues, specifically Ryan said, https://cabforum.org/pipermail/public/2017-April/010748.html:

  • So that leaves the last case - cross-signs. And cross-signs are a complex beast that, done incorrectly, can significantly impair the security of users unnecessary. I know of several Member CA's cross-signs that have resulted in security issues for either relying parties or operational issues for browser members trying to scope appropriately, and I absolutely think we need better guidance here. That's not to say this ballot is meant to solve that issue now, so if that's the only blocker/concern here, maybe we can find the right language to satisfy this.

I don't believe we intended to prohibit the ability of CAs to create cross certificates as part of Ballot 199, did we?

I'd like to suggest we update the Mozilla policy to create a definition for cross certificates that is different from Subordinate CA certificates to permit roots included in the NSS trust store to have cross certificates generated between them (along with a ballot for the BRs to also permit this). Would you be open to that?

Flags: needinfo?(wthayer)

While I won't presume to speak for Mozilla here, I know Google would be opposed. The desired flow is that we have old certify new, rather than have new certify old; this ensures we make forward progress on meaningful certificate profiles, not just for leaves, but for intermediates and roots as well. Multiple CAs have had non-complying roots rejected in the past, and it seems that such a requirement should and would naturally apply to intermediates (including cross-certificates, which are intermediates).

It seems like filing an issue on https://github.com/mozilla/pkipolicy and/or starting a discussion on m.d.s.p. would be a good next step, even if it may not result in the desired outcome.

(In reply to Ryan Sleevi from comment #33)

It seems like filing an issue on https://github.com/mozilla/pkipolicy and/or starting a discussion on m.d.s.p. would be a good next step, even if it may not result in the desired outcome.

I mostly agree with this recommendation, except that I thought the problem was purely a violation of the BRs and not Mozilla policy, in which case it would make more sense to have the discussion on the SCWG public list.

Flags: needinfo?(wthayer)

I've re-started the discussion on this topic:
https://cabforum.org/pipermail/servercert-wg/2019-October/001256.html

You need to log in before you can comment on or make changes to this bug.