Thanks. As noted in your comments, the majority of affected root CAs have indicated that they do not believe that they will have a problem with the proposed deprecation schedule, but I am still considering modifying the wording/timeframes for the four or so CAs who might be affected. For example, one CA operator has since noted that their key is 4096-bit RSA, that they can provide audit documentation of their key generation, and that the transition to another root may be difficult for users of Android and Apple devices. So, I will take a closer look at these four Root CAs as I continue to look to see how the wording or schedule of the original proposal can be tweaked.
Off-hand, here are the Root Certificates from those affected CA operators who I recall have previously expressed concern, one way or another: GlobalSign - https://crt.sh/?id=88 DigiCert - https://crt.sh/?id=76 Chunghwa Telecom - https://crt.sh/?id=17183 Sectigo - https://crt.sh/?id=331986 Others who I believe do not have concerns with the current proposal are: SECOM - https://crt.sh/?id=144 Hong Kong Post - https://crt.sh/?id=4854 Entrust - https://crt.sh/?id=55 GoDaddy - https://crt.sh/?id=39 and https://crt.sh/?id=27 SecureTrust/Viking Cloud - https://crt.sh/?id=95564 Ben On Thu, Sep 1, 2022 at 7:30 AM Filippo Valsorda <fili...@ml.filippo.io> wrote: > Hi Ben, > > I am struggling to understand the link between the CA comments and the > proposal to amend the timeline. > > At least five out of seven affected CAs are ready for the change, which to > me sounds like as good as it usually gets for deprecations. The remaining > CAs don't seem to have explored alternative technical solutions: for > example, why is cross-signing not an option? What does that say about their > intermediate agility and ability to handle an intermediate revocation? > Anyway, what message does amending the timeline to accomodate the slower > CAs send to the rest of the CAs that run more flexible operations? Finally, > what security benefit does amending the timeline provide to Mozilla users? > > Thank you, > Filippo > > 2022-08-25 19:11 GMT+02:00 Ben Wilson <bwil...@mozilla.com>: > > Corey, > > Here is a sampling of responses we've had from other pre-2006 root CAs > that would be affected: > > > "This root still supports 2 TLS subordinate CAs. One certificate expires > in October 2024, and the other expires in July 2029. However, we can move > off this root for TLS issuance." > > > > "We would like to wait until after the expiration of our issuing CA in > September 2023." > > > > "Our root expires in May 2023. We started issuing TLS server certificates > from our new root certificate in July 2019. All TLS server certificates > issued by old root certificate have expired already." > > > > "We have already transitioned away issuance of TLS Server Certificates > from this older root CA." > > > > "Mozilla may turn off the TLS trust bit for this root." > > > > "Our G2 root, which we use for TLS issuance since 2020, has been > cross-signed by our G1 root." > > > > "We submitted a newer root certificate several years ago to another root > program, and it’s still not in their distributed root store. If the root > programs want to start motivating CAs to be more nimble and to rotate our > roots, we need the root programs to do the same." > Given your concerns, and as an alternative to what we previously proposed, > what if we modified the deprecation schedule and required CAs to not issue > new TLS certificates after the given date (unless reissuance were necessary > under a given set of limited circumstances - TBD) and that we remove the > websites trust bit a year later? In other words, the CA would stop issuing > new certificates, except e.g., emergency re-issuance, etc.; we would change > the column heading from "Distrust After Date" to "Stop Issuance"; and a new > column would indicate that Mozilla would submit an NSS Bug to Remove the > <Websites / Email> Trust Bit, which would be effective approximately one > year after the Stop-Issuance column. > > Thanks, > > Ben > > > > On Mon, Aug 22, 2022 at 1:21 PM Ben Wilson <bwil...@mozilla.com> wrote: > > Thanks, Corey > For a while now, I've been reaching out to the pre-2006 root CA operators. > I'll prepare a summary of what they've said regarding their strategies to > continue TLS certificate issuance and post it here. > Thanks again, > Ben > > On Wed, Aug 17, 2022 at 6:52 AM Corey Bonnell <corey.bonn...@digicert.com> > wrote: > > Hi Ben, > > The proposed update to 7.4.1 includes a table that outlines the > distrust/”notBefore” dates of root certificates. For those certificates > issued before 2006, there is a proposed distrust date of April 15, 2024 > (less than 20 months from now). > > > > However, the document then states: > > " It typically takes 2 to 3 years for a root certificate to get included > into the major root stores. Time is also needed to complete the transition > from an older hierarchy to the newer hierarchy before a CA can be > distrusted for TLS.” > > > > This section acknowledges that it takes several years to gain root > ubiquity and seemingly indicates that 20 months is not sufficient time to > transition. To remain consistent with this guidance, I believe the distrust > table needs to be updated to provide a more generous window so CAs have > time to transition. > > > > Thanks, > > Corey > > > > > > *From:* dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> *On > Behalf Of *Ben Wilson > *Sent:* Monday, August 15, 2022 5:28 PM > *To:* dev-secur...@mozilla.org <dev-security-policy@mozilla.org> > *Subject:* Proposed Updates to MRSP to Address Root CA Life Cycles > > > > All, > > > > Here is a set of proposed policy changes for your review and comment. The > full draft document, which I've pasted below, is also available here: > > > https://docs.google.com/document/d/1Hqu-9OxiLiAr4gliSOCAHYpOspbsL4I-sAuwmISWqWg/ > > > > Ben > > > > > --------------------------------------------------------------------------------------------------- > > > Proposed Updates to Mozilla Root Store Policy > > The following changes are proposed to Mozilla’s Root Store Policy > <https://www.mozilla.org/projects/security/certs/policy/>. > > > > *Addition to: Section 7.1 Inclusions* > > CA key material MUST be generated within the three (3) years that precede > the submission of a CA inclusion request. The date of CA key material > generation shall be determined by reference to the auditor’s key generation > ceremony report. > > *New Section 7.4 “Root CA Life Cycles”* > > Mozilla MAY limit the useful life of a CA certificate included in > Mozilla’s root store to 10 years in order to encourage cryptographic > agility, address advancements in computing, and facilitate the transition > to better algorithms. Limiting the useful life of CA certificates is also > warranted because older CA certificates generally subsist with > non-conformities, having been created with (and sometimes maintained with) > older technologies, policies, and practices that were overlooked as > pre-existing when new requirements were introduced by this Policy or the > CA/Browser Forum Baseline Requirements. > > *7.4.1 TLS* > > CA operators SHOULD anticipate that a root CA certificate included in the > Mozilla root store with the websites trust bit enabled will be distrusted > for TLS when its CA key material is over 15 years old. > > For transition purposes, CA certificates in the Mozilla root store will be > distrusted for TLS according to the following schedule: > > Key Material Created > > Distrust for TLS After Date > > Before 2006 > > April 15, 2024 > > 2006-2007 > > 18 years from creation > > 2008-2009 > > 17 years from creation > > 2010-2011 > > 16 years from creation > > After 2011 > > 15 years from creation > > (In the absence of an auditor’s key generation ceremony report, Mozilla > may assume that the key material was generated prior to the “Valid From” > date in the root CA certificate.) > > CA operators MUST apply to Mozilla for inclusion of their next generation > root certificate with the websites trust bit enabled at least 2 years > before the “Distrust for TLS After Date” above. > > *7.4.2 S/MIME* > > CA operators SHOULD anticipate that a root CA certificate included in the > Mozilla root store with the email trust bit enabled will be distrusted for > S/MIME when its CA key material is over 20 years old. > > For transition purposes, CA certificates in the Mozilla root store will be > distrusted for email according to the following schedule: > > Key Material Created > > Distrust for Email After Date > > Before 2006 > > April 15, 2029 > > 2006-2007 > > 23 years from creation > > 2008-2009 > > 22 years from creation > > 2010-2011 > > 21 years from creation > > After 2011 > > 20 years from creation > > CA operators MUST apply to Mozilla for inclusion of their next generation > root certificate with the email trust bit enabled at least 2 years before > the “Distrust for Email After Date” above. > Why 15 Years for TLS? > > It typically takes 2 to 3 years for a root certificate to get included > into the major root stores. Time is also needed to complete the transition > from an older hierarchy to the newer hierarchy before a CA can be > distrusted for TLS. Therefore, a 15-year term allows for approximately 10 > years of root CA use within the Mozilla root store. > Reasons for this Change > > *Cryptographic Agility* > > Over the past decade, there have been multiple warnings that cryptographic > algorithms currently in use will be vulnerable to attack by the year 2030, > or sooner. Some experts believe that there is a 15% chance that RSA and ECC > will be broken by 2026. While these are only predictions, by the time > they’re proven, it will be too late. We need to prepare now, but the > current problem is that many root CA certificates in the Mozilla root store > will still be valid in 2030, and some even until 2046. When RSA and ECC > root certificates are long-lived and then relied upon globally, they make > it difficult to transition to something else. If one considers the > historical advances we’ve made in computer processing speed over the past > fifty years, the next several years will be a critically short time in > which to transition. There is also the threat of practical quantum > computing, which is predicted to break the security of nearly all modern > public-key cryptographic systems, including the Web PKI. Even without > quantum computing, cryptographic weaknesses will be discovered or there > will be advances in technology supporting cryptanalysis, and it will be > necessary to replace cryptographic algorithms. > > Currently-used algorithms like RSA and ECC will be susceptible to cracking > by quantum brute force based on Shor’s algorithm, which uses a quantum > computer. Global investment in quantum computing is currently in the tens > of billions of dollars, and it is expected to grow by the billions over the > next several years. Also, over the next several years, our widely-used > public key algorithms will need to be replaced with quantum-resistant > alternatives. This will be a tremendous change management effort. We need > to make significant changes to the Web PKI’s infrastructure. Members of the > Mozilla Community know from experience that making infrastructural changes > like we’re faced with here can take time to implement. If transition from > the current cryptographic solutions to quantum-resistant algorithms takes > too long, then until that happens, everyone will be exposed to privacy and > security risks. We all need to be proactive instead of reactive. There is > too much risk not to take some action now. > > Cryptographic agility is the ability to replace cryptographic primitives, > algorithms, and protocols efficiently at reasonable costs and with limited > impact on operations. Mozilla is committed to the agile management of the > root store and the timely replacement of root certificates to make the Web > PKI more cryptographically agile so that we can make rapid transitions to > new cryptographic primitives and algorithms. Practicing cryptographic > agility now is necessary for the transition that CA operators will need to > make in the future as quantum computing becomes more prevalent and as they > need to implement post-quantum algorithms and other related solutions. > > *Old Roots and CA Hierarchies may not comply with New Requirements* > > It cannot be said that root key pairs and certificates created between > 1998-2012 meet the CA/Browser Forum requirements and Mozilla standards that > now exist. For instance, auditor-witnessed key generation on cryptographic > hardware was only established unambiguously when the CA/Browser Forum > adopted version 1 of the Baseline Requirements for the Issuance and > Management of Publicly-Trusted Certificates. > https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf , > effective July 1, 2012. > > Root CAs created in the late 1990s and early 2000s are too old. Many are > 2048-bit RSA. Some root CAs have been sold and transferred numerous times, > and they cannot provide full auditor-provided attestations concerning key > generation, secure transportation, cradle-to-grave continuous key > protection, and ongoing policy adherence. > Background/History > Late 1990s - Early 2000s > > Back in 1998 and 1999 when some roots were created, there were very > minimal requirements to be included as trust anchors in browser software. > At the time, some root key pairs were even generated and stored in > software. Soon, Microsoft began requiring that root keys be generated and > held in hardware, and that “the CA follow appropriate technical security > controls for the generation and delivery of public keys and the protection > of private keys.” Specifically, “hardware crypto modules rated at FIPS > 140-1 Level 2, ITSEC E3 or Common Criteria EAL4 (or higher) for CA > signing key generation, storage and signing operations”. > 2006 - Adoption of the Extended Validation Guidelines > > In October 2006, the CA/Browser Forum adopted the Extended Validation > Guidelines, which contained requirements for root certificates that would > be trusted for EV treatment in browsers, including that auditors witness > root key generation (attend the key ceremony) and provide a key generation > report. > 2008 - Microsoft Technical Requirements > > In 2008, version 1.1 of Microsoft’s Technical Requirements stated that > 2048-bit roots had to expire before 2030, but “longer expiration may be > afforded to larger root key sizes.” > https://social.technet.microsoft.com/wiki/contents/articles/20899.windows-root-certificate-program-technical-requirements-version-1-1.aspx > <https://social.technet.microsoft.com/wiki/contents/articles/20899.windows-root-certificate-program-technical-requirements-version-1-1.aspxhttps:/social.technet.microsoft.com/wiki/contents/articles/20899.windows-root-certificate-program-technical-requirements-version-1-1.aspx> > 2011 - Adoption of the Baseline Requirements > > In November 2011, the CA/Browser Forum adopted version 1.0 of the Baseline > Requirements for the Issuance and Management of SSL Certificates (BRs) with > an effective date of July 1, 2012. Section 17.7 of the BRs required key > generation within cryptographic modules meeting applicable technical and > business requirements and that auditors witness root key generation (or > examine a video-recording of the key ceremony) and provide a key generation > report. While some CAs may have been doing these practices before the > adoption of the BRs, there is no publicly maintained evidentiary > documentation or other assurance that such is the case. > > > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaGstSy2VGG7R63FBVxXm0rjWRBbVQDR_zHwv8RfeGDeQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaGstSy2VGG7R63FBVxXm0rjWRBbVQDR_zHwv8RfeGDeQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaneQvrQyuAG35xvdiJXdZFpvR99hpXPj0_1AWaBZ22TA%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaneQvrQyuAG35xvdiJXdZFpvR99hpXPj0_1AWaBZ22TA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/02123a13-e89f-4aa8-8ba4-9656e2b6af17%40www.fastmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/02123a13-e89f-4aa8-8ba4-9656e2b6af17%40www.fastmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYW2Dwaph47UKKRFNKG9LtvjVJxw1cBjA8g1c2wmXbHng%40mail.gmail.com.
