Hey Ben, I know discussion here has been quiet, but in light of other threads going on, I actually want to say I'm very supportive of GlobalSign's plan here, and surprised they didn't call more attention to it, because it's something to be proud of.
As I understand it, and happy to be corrected if I've made a mistake here, GlobalSign is actively working to transition their hierarchy to one that reflects a modern, good practice implementation. That's something they should be proud of, and something all CAs should take note of. In particular, they're transitioning to single-purpose roots (e.g. all TLS, all e-mail), in order to reduce the risk to relying parties from roots that exist cross-purposes. You're absolutely correct for calling out GlobalSign's past incidents, and I don't want to appear to be suggesting that simply spinning up new roots wipes the old slate clean, but this is a huge step in the right direction, and does reflect good practice. I will disclose that GlobalSign reached out, as have several other CAs (PKIoverheid, Sectigo, DigiCert), to invite feedback in their design and discuss some of their challenges, and I think that's also the kind of positive, proactive behavior worth encouraging. Within the context of the incident reports, I do want to also acknowledge that GlobalSign has consistently improved the quality of their reports. As the OCSP issue shows, the level of detail and clarity in their communications, and their providing artifacts, has been a huge help in addressing and assuaging concerns. Rather than purely looking at the number of incidents, and instead looking at how the incident reports are handled, this is good progress. While some bugs did feel like they dragged out (e.g. 1575880), even then, GlobalSign was proactive in communicating both the completion of past actions as well as next steps, with clear timetables. GlobalSign has already proactively addressed some of the other things one might expect from a "modern" CA - for example, supporting and enabling automation for their customers, both "retail" and "managed CA/Enterprise" (via AEG), and so I do see a positive trend in addressing some of the systemic issues here. That's not to say things are perfect: for example, the mixing of TLS profiles (DV, OV, EV) in a single hierarchy means that there are still a number of systemic risks which we've seen as patterns, both from GlobalSign and other CAs, in terms of audit and audit scopes and proper validation of information, but I do think this is trending closer to what would be good for all CAs to think about. The sooner we can get to sunsetting GlobalSign's legacy roots, the better, and so I definitely think it would be encouraging to see them help migrate customers sooner than waiting on natural expiration alone, just like I think continuing to shorten lifetimes would be another very positive sign. However, I understand and recognize there are complexities here that may prevent that, but I didn't want folks to think this was "as good as it gets" ;) On Mon, Jan 11, 2021 at 7:59 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This is to announce the beginning of the public discussion phase of the > Mozilla root CA inclusion process for GlobalSign. > > See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, > (Steps 4 through 9). > > GlobalSign has four (4) new roots to include in the root store. Two roots, > one RSA and another ECC, are to support server authentication (Bugzilla Bug > # 1570724 <https://bugzilla.mozilla.org/show_bug.cgi?id=1570724>) while > two > other roots are for email authentication, RSA and ECC (Bugzilla Bug # > 1637269 <https://bugzilla.mozilla.org/show_bug.cgi?id=1637269>). > > Mozilla is considering approving GlobalSign’s request(s). This email begins > the 3-week comment period, after which, if no concerns are raised, we will > close the discussion and the request may proceed to the approval phase > (Step 10). > > *A Summary of Information Gathered and Verified appears here in these two > CCADB cases:* > > > https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000469 > > > https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000596 > > *Root Certificate Information:* > > *GlobalSign Root R46 * > > crt.sh - > > https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9 > > Download - https://secure.globalsign.com/cacert/rootr46.crt > > *GlobalSign Root E46* > > crt.sh - > > https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058 > > Download - https://secure.globalsign.com/cacert/roote46.crt > > *GlobalSign Secure Mail Root R45 * > > crt.sh - > > https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974 > > Download - https://secure.globalsign.com/cacert/smimerootr45.crt > > *GlobalSign Secure Mail Root E45 * > > crt.sh - > > https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19 > > Download - https://secure.globalsign.com/cacert/smimeroote45.crt > > > *CP/CPS:* > > https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf > > The current GlobalSign CPS is version 9.6, published 29-December-2020. > > Repository location: https://www.globalsign.com/en/repository > > *BR Self-Assessment* (Excel) is located here: > > https://bugzilla.mozilla.org/attachment.cgi?id=9082310 > > *Audits:* GlobalSign is audited annually in accordance with the WebTrust > criteria by Ernst & Young, Belgium, which found in June 2020 that > “throughout the period April 1, 2019 to March 31, 2020, GlobalSign > management’s assertion, as referred to above, is fairly stated, in all > material respects, in accordance with the WebTrust Principles and Criteria > for Certification Authorities - SSL Baseline with Network Security, Version > 2.3.” The WebTrust audit noted the following 13 Bugzilla incidents, which > had been previously reported as of that audit date: > > 1 Misissuance of QWAC certificates. > > 2 Issue with an OCSP responder status. > > 3 Some SSL certificates with US country code and invalid State/Prov have > been issued. > > 4 ICAs in CCADB, without EKU extension are listed in WTCA report but not in > WTBR report. > > 5 OCSP responders found to respond signed by the default CA when passed an > invalid issuer in request. > > 6 Wrong business category on 3 EV SSL certificates. > > 7 OCSP Responder returned invalid values for some precertificates. > > 8 Customer running an on-premise (technically-constrained) CA that chains > to a GlobalSign root, issued certificates without AIA extension. > > 9 Misissued 4 certificates with invalid CN. > > 10 Certificates with Subject Public Key Info lacking the explicit NULL > parameter. > > 11 Untimely revocation of TLS certificate after submission of private key > compromise. > > 12 Unable to revoke 2 noncompliant QWACs within 5 days. > > 13 Unable to revoke noncompliant ICA within 7 days > > > > *Incident Reports / Mis-Issuances * > > The following bugs/incidents remain open and are being worked on. > > 1667944 <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944> > > Empty SingleExtension in OCSP responses > <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944> > > 1651447 <https://bugzilla.mozilla.org/show_bug.cgi?id=1651447> > > Failure to revoke noncompliant ICA within 7 days > <https://bugzilla.mozilla.org/show_bug.cgi?id=1651447> > > 1591005 <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005> > > ICAs in CCADB, without EKU extension are listed in WTCA report but not in > WTBR report <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005> > > 1649937 <https://bugzilla.mozilla.org/show_bug.cgi?id=1649937> > > Incorrect OCSP Delegated Responder Certificate > <https://bugzilla.mozilla.org/show_bug.cgi?id=1649937> > > 1668007 <https://bugzilla.mozilla.org/show_bug.cgi?id=1668007> > > Invalid stateOrProvinceName value > <https://bugzilla.mozilla.org/show_bug.cgi?id=1668007> > > 1664328 <https://bugzilla.mozilla.org/show_bug.cgi?id=1664328> > > SHA-256 hash algorithm used with ECC P-384 key > <https://bugzilla.mozilla.org/show_bug.cgi?id=1664328> > > 1575880 <https://bugzilla.mozilla.org/show_bug.cgi?id=1575880> > > SSL Certificates with US country code and invalid State/Prov > <https://bugzilla.mozilla.org/show_bug.cgi?id=1575880> > > > > No misissuances were found under these roots, and the CA certificates > passed technical tests. > > Thus, this email begins a three-week public discussion period, which I’m > scheduling to close on or about Tuesday, 2-February-2021. > > > > Sincerely yours, > > Ben Wilson > > Mozilla Root Program > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
