2022-09-08 00:11 GMT+02:00 Ben Wilson <[email protected]>: > 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.
Thank you for the details. Key generation audits are nice, but without ongoing audits from that moment to the present, I believe they don't mitigate the security concerns around what that key might have signed over its lifetime. Could the details of the Android and Apple client compatibility issues be shared on-list, ideally by the affected CAs? It feels like an opportunity for the ecosystem to learn something if nothing else. > 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 <[email protected]> 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 <[email protected]>: >>> 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 <[email protected]> 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 <[email protected]> >>>> 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:* [email protected] <[email protected]> >>>>> *On Behalf Of *Ben Wilson >>>>> *Sent:* Monday, August 15, 2022 5:28 PM >>>>> *To:* [email protected] <[email protected]> >>>>> *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 >>>>> "[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%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 >>> "[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%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 >> "[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/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 "[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/db6241fb-c200-4fe0-9821-62ee770264b6%40www.fastmail.com.
