Ryan,
We are actively working on getting our new roots trusted. In parallel, we plan to create new ICAs from the G5 Roots this year – that process has already started. By the end of 2022, DigiCert plans to have G5 issued ICA replacements available to our customers. We have not started building the cross-signs yet from existing roots but we are working on plans for that in parallel with our root inclusion efforts here. We hope to limit the number of cross-signed certificates needed to support the transition effort but realize that we may have to cut cross-certs from many (if not all) of the old roots to the new roots. Our cross-signs will correspond to our plan to ensure ubiquity and root segmentation by purpose. For example, we will likely cross-sign using the Assured ID G2 root for S/MIME. Thanks, Brenda From: Ryan Sleevi <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, March 16, 2022 at 7:55 AM To: Brenda Bernal <[email protected]> Cc: Ben Wilson <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Public Discussion of DigiCert's Inclusion Request Brenda: I’m glad to hear this was trivially resolved, but what I’m unclear of is how it happened and wasn’t detected until it was raised. That is, given DigiCert’s past issues in failing to notice this, my understanding of DigiCert’s past commitments is that they incorporated review of that very page as part of the CCADB update procedures, in addition to the CCADB update automation. I bring it up now, in the discussion of root inclusion that I do believe would be an overall net positive to users, because it highlights that past problems are still unfortunately repeating. The severity of the problem, which based on the provided explanation seems quite minor, is less the issue, but rather, the repeat nature of such issues and the failure of past efforts to remediate and prevent such issues. Do I think it should block inclusion of these roots? No, not at all - if anything, it highlights the value of such separation of purposes, to greater isolate the risk from unmitigated systemic issues. However, I do think it leads to the next question: namely, given such past patterns are still happening, what’s the timeline to transition new certificate issuance to these new paths? Are we talking an order of weeks, months, or years? Presumably, removal of any old roots cannot occur with zero disruption until after the expiration of the extant certificates, so figuring out the timeline is useful. Similarly, have variants of these roots been cross-signed from the existing roots? If so, that might allow for a sooner transition, independent of any decision here, but which can further highlight the value of such a transition. On Tue, Mar 15, 2022 at 9:50 PM Brenda Bernal <[email protected]> wrote: Dear Ryan, Thank you for pointing out your observation, and we have identified the issue to be related to how CCADB is chaining for cross signed roots. All intermediates and roots that are publicly trusted are included in our last WebTrust audit and have the proper CP/CPS pointers in CCADB. The Root certificates that these hierarchies were cross signed under were our legacy Symantec ones that have been distrusted and an expired root. Unfortunately, CCADB was taking the path to those roots rather than to the trusted root which is correct. We were following the Mozilla recommended process of having all intermediate and ICAs same as parent for audit and CPS. As this Root was one of the ones distrusted in 2021, it did not get the policy updates in our annual audit submission. We have discussed the issue with Ben and have used a "re-parenting" process that fixed this chaining issue. Thank you, Brenda Bernal on behalf of DigiCert From: <[email protected]> on behalf of Ryan Sleevi <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Sunday, March 13, 2022 at 12:34 PM To: Ben Wilson <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: Public Discussion of DigiCert's Inclusion Request I happened to note that DigiCert has, once again, a set of incomplete disclosures - https://crt.sh/mozilla-disclosures#disclosureincomplete This has happened in the past - [1] [2] [3], with a more fuller history of previous incidents in [4]. DigiCert folks: Could you comment and explain? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1499585 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1451950 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1650910 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1650910#c30 On Wed, Mar 9, 2022 at 5:51 PM Ben Wilson <[email protected]> wrote: All, This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process (https://wiki.mozilla.org/CA/Application_Process#Process_Overview - Steps 4 through 9) for DigiCert’s inclusion request (Bug # 1706228, CCADB Case # 743) for the following root CA certificates: DigiCert TLS RSA4096 Root G5 (websites trust bit, EV) Download – https://cacerts.digicert.com/DigiCertRSA4096RootG5.crt.pem crt.sh - https://crt.sh/?SHA256=371A00DC0533B3721A7EEB40E8419E70799D2B0A0F2C1D80693165F7CEC4AD75 DigiCert TLS ECC P384 Root G5 (websites trust bit, EV) Download – https://cacerts.digicert.com/DigiCertECCP384RootG5.crt.pem crt.sh – https://crt.sh/?SHA256=018E13F0772532CF809BD1B17281867283FC48C6E13BE9C69812854A490C1B05 DigiCert SMIME RSA4096 Root G5 (email trust bit) Download – https://cacerts.digicert.com/DigiCertSMIMERSA4096RootG5.crt.pem crt.sh - https://crt.sh/?SHA256=90370D3EFA88BF58C30105BA25104A358460A7FA52DFC2011DF233A0F417912A DigiCert SMIME ECC P384 Root G5 (email trust bit) Download – https://cacerts.digicert.com/DigiCertSMIMEECCP384RootG5.crt.pem crt.sh - https://crt.sh/?SHA256=E8E8176536A60CC2C4E10187C3BEFCA20EF263497018F566D5BEA0F94D0C111B Mozilla is considering approving DigiCert’s request to add these four (4) roots as trust anchors with the trust bits and EV-enabled as indicated above. Repository: The DigiCert document repository is located here: https://www.digicert.com/legal-repository Relevant Policy and Practices Documentation: Certificate Policy, v. 5.9, dated January 21, 2022 https://www.digicert.com/content/dam/digicert/pdfs/legal/digicert-cp-v5-9.pdf Certification Practices Statement, v. 5.9, dated January 21, 2022 https://www.digicert.com/content/dam/digicert/pdfs/legal/digicert-cps-v5-9.pdf Self-Assessments and Mozilla CPS Reviews are located as attachments in Bug # 1706228: Mozilla Review of DigiCert CP/CPS and Compliance Self-Assessment (xls) DigiCert Replies to CP/CPS Review and Compliance Self-Assessment (xls) Audits: Annual audits have been performed by BDO. The most recent audits were completed for the period ending September 30, 2021. See https://www.digicert.com/webtrust-audits. Incidents DigiCert has no open incidents in Bugzilla. In the past year, there have been five incidents involving DigiCert, which are now closed satisfactorily: 1727963 DigiCert: Truncation of Registration Number 1744795 DigiCert: Issuance of certs with weak keys (ROCA) 1710444 DigiCert: Invalid stateOrProvinceName 1710856 DigiCert: Invalid localityName 1714439 DigiCert: Incorrect RegNumber-Org Type combination I have no further questions or concerns about DigiCert’s inclusion request; however, I urge anyone with concerns or questions to raise them on this list by replying directly in this discussion thread. Likewise, a representative of DigiCert must promptly respond directly in the discussion thread to all questions that are posted. This email begins the 3-week comment period, which I’m scheduling to close on or about March 31, 2022, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10). Sincerely yours, Ben Wilson Mozilla Root Program Manager -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYXwMGTf4kxr7KhWr5fWd-aiJss4S0rjOz6F4-3wfFGEA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG9YxHBGf9ERxvf%3D3z3ZtfQi8%3DB2JgdAnZZwhmCsZ%3D%3DVg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/B02AEB46-CFEB-41C3-A1DB-97B281A2F470%40digicert.com.
smime.p7s
Description: S/MIME cryptographic signature
