So seven CAs could be affected by the timeline. Six of them say it is not a problem for them, and one of them has a complaint based on another root store. Does that CA have newer roots in Mozilla's root store? Could they use cross-signs to achieve compatibility with the other root store?
Can we get names on these CAs? Since we are talking about a deprecation, I don't think it is relevant to talk generically about a CA that could exist but doesn't. Based on the comments you quoted I can't see anything that would be of concern to your originally proposed timeline. Den tor. 25. aug. 2022 kl. 19.11 skrev 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/HistoryLate 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/CACAF_WhJd7i2gYLyuMv6BvBQe2sEPL0anX2%2BM%3DuRidrTQxqWHQ%40mail.gmail.com.
