Proposed Updates to MRSP to Address Root CA Life Cycles

1068 views
Skip to first unread message

Ben Wilson

unread,
Aug 15, 2022, 5:28:40 PMAug 15
to dev-secur...@mozilla.org
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: 

Ben

---------------------------------------------------------------------------------------------------

Proposed Updates to Mozilla Root Store Policy

The following changes are proposed to Mozilla’s Root Store 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

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.


Corey Bonnell

unread,
Aug 17, 2022, 8:52:19 AMAug 17
to Ben Wilson, dev-secur...@mozilla.org

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@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.

Ben Wilson

unread,
Aug 22, 2022, 3:22:07 PMAug 22
to Corey Bonnell, dev-secur...@mozilla.org
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

Ben Wilson

unread,
Aug 25, 2022, 1:11:26 PMAug 25
to Corey Bonnell, dev-secur...@mozilla.org
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 

Corey Bonnell

unread,
Aug 26, 2022, 7:55:41 AMAug 26
to Ben Wilson, dev-secur...@mozilla.org

Hi Ben,

> 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.

 

If I’m understanding this proposal correctly, then any issuance after the “Stop Issuance” date is a violation of Mozilla Policy. This differs from the previous proposal where any certificates issued after the “Stop Issuance” date are merely not trusted by Firefox. In other words, it’s a technical control without any corresponding policy restriction.

 

I think prohibiting TLS issuance via policy vs. implementing technical controls (i.e., removal of the Websites bit) may pose interoperability issues with other trust stores/platforms, as their plans for legacy root transition may not be as mature as Mozilla’s. The response that you quoted above is especially relevant here: “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.”

 

Additionally, a prohibition on issuance will prevent CAs from issuing Test Website certificates as required by BR section 2.2.

 

For these reasons, I’d advocate for complete removal of the Websites trust bit 398 days after the proposed “Stop Issuance” date and no restriction on issuance. A complete removal of the Websites trust bit will protect Firefox users from CA Private Keys whose provenance and protection has been called into question while also providing sufficient time for CAs and Subscribers to migrate to newer hierarchies.

 

Thanks,

Corey

Martijn Katerbarg

unread,
Aug 30, 2022, 12:23:35 PMAug 30
to dev-secur...@mozilla.org, corey....@digicert.com, dev-secur...@mozilla.org, bwi...@mozilla.com

Hi Ben,

I agree with Corey. The proposed TLS timeline will remove a number of root certificates in less than 20 months.

While I don’t see any real issue with removing trust in CA certificates after 15 years going forward, we should raise the initial date in the proposal for this to go into effect so CAs have time to deal with it as well as a hard target date.

Given that it can take 2 to 3 years (sometimes more!) for roots to get included, we should be adding time for processes at the CA to start up and get their internal approval, key ceremony and signings completed and set a bar at around 4 years.

On the other hand, I’m struggling to see why S/MIME should keep a longer usability life. If cryptographic agility is the main driver of this change, then we should keep lifetimes for TLS and S/MIME the same. This would also keep the target rollover dates for new hierarchies the same, potentially lowering the number of inclusion request cases.

Maybe there’s a path forward of combining the distrust dates of TLS and S/MIME, moving both initial distrust dates to somewhere in between, the end of 2026 or early 2027 instead.

Regards,

Martijn

Op vrijdag 26 augustus 2022 om 13:55:41 UTC+2 schreef corey....@digicert.com:

Dimitris Zacharopoulos

unread,
Aug 30, 2022, 2:39:47 PMAug 30
to Ben Wilson, dev-secur...@mozilla.org


On 16/8/2022 12:28 π.μ., Ben Wilson wrote:

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.


Why 3 years instead of 5? What are the security benefits of a key being generated 3 vs 5 years ago? The Chrome Root Program Policy states that it will accept keys generated 5 years ago so perhaps there is no significant reason to justify this policy divergence.


Thanks,
Dimitris.

Jesper Kristensen

unread,
Aug 31, 2022, 3:36:03 PMAug 31
to dev-secur...@mozilla.org
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.

Filippo Valsorda

unread,
Sep 1, 2022, 9:30:27 AMSep 1
to dev-secur...@mozilla.org
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

Ben Wilson

unread,
Sep 7, 2022, 6:11:21 PMSep 7
to Filippo Valsorda, jespe...@gmail.com, dev-secur...@mozilla.org
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:

Chunghwa Telecom - https://crt.sh/?id=17183

Others who I believe do not have concerns with the current proposal are:

Hong Kong Post - https://crt.sh/?id=4854
SecureTrust/Viking Cloud - https://crt.sh/?id=95564

Ben

Ben Wilson

unread,
Sep 7, 2022, 7:02:37 PMSep 7
to Dimitris Zacharopoulos, dev-secur...@mozilla.org
Hi Dimitris,
Thanks. I don't know why Chrome chose five years because I can't think of a scenario where a CA operator would take 4-5 years to submit their root CA for inclusion in the trust store. Whereas, three years seemed more reasonable and manageable.
Ben

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Filippo Valsorda

unread,
Sep 7, 2022, 8:42:03 PMSep 7
to Ben Wilson, jespe...@gmail.com, dev-secur...@mozilla.org
2022-09-08 00:11 GMT+02:00 Ben Wilson <bwi...@mozilla.com>:
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.

Dimitris Zacharopoulos

unread,
Sep 8, 2022, 3:13:12 AMSep 8
to Ben Wilson, dev-secur...@mozilla.org


On 8/9/2022 2:02 π.μ., Ben Wilson wrote:
Hi Dimitris,
Thanks. I don't know why Chrome chose five years because I can't think of a scenario where a CA operator would take 4-5 years to submit their root CA for inclusion in the trust store. Whereas, three years seemed more reasonable and manageable.

Without being 100% certain, I believe there is a use case where a CA performs a key generation ceremony witnessed by an external Qualified auditor, then "park" those keys making sure they are covered in annual audits by providing "key protection" audit reports for the keys not associated with Root CAs. This has been presented in CABF F2F meetings several times. I assume that a CA with "parked keys" could pick some of those keys up 4 years from creation and create a Root CA(s) to be included in Root stores without needing to perform another (costly?) keygen witnessed by an external auditor.

Either way, I'm more concerned about the deviation from the Chrome Root Store Policy than the decision of 3 or 5 years :) Hopefully the two programs can align (either Chrome change to 3 years or Mozilla change to 5).


Dimitris.

Ryan Dickson

unread,
Sep 9, 2022, 8:56:38 AMSep 9
to Dimitris Zacharopoulos, Ben Wilson, dev-secur...@mozilla.org

Hi all,


TL;DR: We’re willing to consider moving the key freshness requirement from 5 years to 3 in a future policy update. Reducing the key-freshness requirement was always part of our long-term strategy. 


Dimitris’ use-case description is what we were hoping to accommodate. We’ve seen key generation audit reports where over 50 keys were generated at once, with the specific acknowledgment that the keys were created for future use (i.e., “parked”). Even a year after generation, we do not observe the corresponding public key included in publicly-available certificates (or, by extension, public root program application queues). We’ve even observed an audit report that included over 150 keys. To be clear, this is not a commentary on this practice; I’m simply highlighting the existence of the use case described by Dimitris. 


In any event, our long-term plan before Ben’s post was to reduce the “key-freshness” requirement introduced in our V1.1 policy update. One of the reasons we did not initially require a shorter key-freshness period was because we recognize the effort, cost, and time commitment required by CAs to apply to root programs - and ultimately become “publicly trusted.” Imposing a more strict key-freshness requirement when one did not previously exist in any public root program policy would have resulted in additional churn by CA owners observed in other public root program application queues without guaranteed security value. So, ultimately, we chose five years to balance practical security goals (described below) and the planned launch of our program, with a longer-term goal of eventually reducing this period after better understanding the impact on applicants.


We value the use of “fresh” key material because:

  • When coupled with our future proposed CA term limit, it establishes a ceiling for the maximum time a key that has been unknowingly compromised could impact the security of Chrome’s users. 

  • The Baseline Requirements and audit schemes permitted therein have been continuously improving since their inception. Aligning with modern requirements, practices, and audit frameworks is the only way of benefiting from that improvement. For example, WebTrust’s lifecycle management audit as we know it today wasn’t established until 2019.

  • Similar to the Baseline Requirements and corresponding audit schemes, the same continuous improvement is true for the software libraries and systems that generate and protect key material.

  • As above, it allows the ecosystem to realize the benefits of continuous improvement efforts made by CAs regarding the ongoing management of key generation scripts and ceremonies.

  • It promotes agility. 

  • Being well-versed and well-rehearsed in performing key generation ceremonies will prepare us better for the future (i.e., preparing for a “post-quantum” world where we may quickly need to instantiate new CAs).


Related to this issue, in a future policy update, we may clarify our expectations regarding how “parked keys” must be audited and represented in audit statements, similar to the structured reporting format required for CA certificates (see Section 8.6 of the BRs).


Thanks, and please let me know if there are any questions!


- Ryan

[on behalf of the Chrome Root Program]



Ben Wilson

unread,
Sep 9, 2022, 10:40:24 AMSep 9
to Ryan Dickson, Dimitris Zacharopoulos, dev-secur...@mozilla.org
All,
For the sake of uniformity, I think we're willing to synchronize with the Chrome 5-year limit on key generation.  I'll make that change for the next version announced.
Ben

Li-Chun CHEN

unread,
Sep 14, 2022, 8:11:47 AMSep 14
to dev-secur...@mozilla.org, Filippo Valsorda, dev-secur...@mozilla.org, bwi...@mozilla.com, jespe...@gmail.com

Hi, Fillppo,

 

    About  the details of the Android client compatibility and your comment "why is cross-signing not an option".  You could see Hongkong Post CA's case in mdsp as https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/a2vWmLIKZy4 and Hongkong Post CA's announcement in https://www.ecert.gov.hk/news/press/95.html.   Please also search  "Android Fragmentation" key word in internet.


      I quoat some information from Hongkong Post CA as below :

    “Our several major subscribers’ of public services have recently completed research among mobile device users in Hong Kong.  It revealed that usage of the old Android devices version 10 or below (not yet pre-loaded with Root CA3) could only drop to below 5% for the Hong Kong mobile users at least after 6 years, taking into account that low-income families would slowly replace their old mobile devices.”

      Note that " Root CA3   ("Hongkong Post Root CA 3" ) has been included in Mozilla and Microsoft in May 2019, Google in September 2020, and Apple in October 2021. Therefore, subscribers are no longer required to install the cross-certificate to applications such as web servers for being trusted by common web browsers, when the web browser users use any of the following web browsers on supported platforms ("Supported Web Browser"): -

     Google Chrome and other supported web browsers on Android 11 or above

     Microsoft Edge and other supported web browsers on Windows 10 or above

     Apple Safari and other supported web browsers on iOS 15 or above, iPadOS 15 or above, macOS 12 or above.

     Mozilla Firefox version 68 or above on all supported platforms."

 

       "Since 2019, all TLS server certificates have been rolled-over to a new Hongkong Post Root CA3 Certificate ("Root CA3") to replace the old Root CA1 which is due for expiry in May 2023.  We have also implemented a cross-certificate signed by the old Root CA1, valid from Aug 2017 to May 2023 in enabling end-users of Hong Kong who are using old version of desktop/mobile devices pre-loaded with the old Root CA1 only to access local websites using TLS server certificates issued under Root CA3. "


   “A substantial number of Hong Kong residents using Android version 10 or below, not yet pre-loaded with Root CA3.  Therefore, we plan to model the previous practice of "Let's Encrypt" in managing similar expiry of its Root Certificate in 2021 in order to minimize the impact of accessibility of local websites governed under Root CA3 by old Android device users arising from the expiry of Root CA1. “ 

   "In order to minimize the impact of accessibility of local websites using our TLS server certificates by Hong Kong mobile device users to a manageable level, we consider issuing the new cross-certificate signed by Root CA1 extended by a longer transition period of 6 years or more (instead of 3 years to May 2026). Taking into account that during the transition period, the security strength would not be affected along our existing certificate chain of trust. We have re-confirmed with our auditor to ensure our revised plan with no compliance concerns."


    Note that Hong Kong Post CA's Root CA1 is RSA 2048 with SHA-1. Their new cross-sign certificate RSA 4096 with SHA-256 i:https://crt.sh/?id=7224214828

 

    Thanks to Mr. Man Ho of Hongkong Post Certification Authority, Certizen . 

 

   Sincerely Yours,

 

             Li-Chun Chen

             

 


Filippo Valsorda 在 2022年9月8日 星期四上午8:42:03 [UTC+8] 的信中寫道:

Ben Wilson

unread,
Sep 19, 2022, 1:44:26 PM (11 days ago) Sep 19
to Li-Chun CHEN, dev-secur...@mozilla.org, Filippo Valsorda, jespe...@gmail.com
Here is another option (deleting the other MRSP language previously proposed):

Section 7.4 “Root CA Life Cycles” 

Root CA certificates included in the Mozilla root store will be distrusted when their CA key material is over 15 years old. The date of CA key material generation SHALL be determined by reference to the auditor’s key generation ceremony report. For key material generated before July 1, 2012, Mozilla will assume that the key material was generated on the “Valid From” date in the root CA certificate. For transition purposes, root CA certificates in the Mozilla root store will be distrusted according to the following schedule:  

Key Material Created

Distrust Date

Before January 1, 2006

April 15, 2025

2006-2007

April 15, 2026

2008-2009

April 15, 2027

2010-2011

April 15, 2028

2012- April 14, 2014

April 15, 2029

April 15, 2014 - present

15 years from creation

This schedule is subject to change if the underlying algorithms become more susceptible to cryptanalytic attack.

CA operators MUST apply to Mozilla for inclusion of their next generation root certificate at least 2 years before the Distrust Date above.


Thoughts?

Ben

Corey Bonnell

unread,
Sep 20, 2022, 5:31:31 PM (10 days ago) Sep 20
to Ben Wilson, Li-Chun CHEN, dev-secur...@mozilla.org, Filippo Valsorda, jespe...@gmail.com

Hi Ben,

I like this approach and timeline as it completely removes the old CA key material in question from the ecosystem while providing sufficient runway (2-3 years) for the transition to newer hierarchies.

 

Thanks,

Corey

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Jeremy Rowley

unread,
Sep 21, 2022, 11:39:55 AM (9 days ago) Sep 21
to Ben Wilson, Li-Chun CHEN, dev-secur...@mozilla.org, Filippo Valsorda, jespe...@gmail.com

Hey Ben,

 

s/MIME certificates are issued for 3 years and often put on hardware. This means that s/MIME certificates issued today will be distrusted before their expiration if signed by one of the impacted roots. The logic behind applying the removal to sMIME is also weird as the BRs for s/MIME don’t exist (yet). This means the concern over s/MIME older roots and their operation under the standards is quite different than TLS. I think we should either: 1) extend the timeline for s/MIME so its 3 years from whenever the last issuance date is or 2) apply a notBefore distrust to sMIME on the dates listed below. There’s also some confusion on what distrust means because Mozilla has two different ways to distrust a root – removal or notBefore. How about something like this:


Root CA certificates included in the Mozilla root store will be distrusted when their CA key material is over 15 years old. The date of CA key material generation SHALL be determined by reference to the auditor’s key generation ceremony report. For key material generated before July 1, 2012, Mozilla will assume that the key material was generated on the “Valid From” date in the root CA certificate. Under this section and on the date listed in this section, Mozilla will remove the root’s TLS bit and set a notBefore rule for s/MIME certs. Mozilla will remove the roots completely from the root store 3 years after the notBefore date. For transition purposes, root CA certificates in the Mozilla root store will be distrusted according to the following schedule:  

Key Material Created

Distrust Date

Before January 1, 2006

April 15, 2025

2006-2007

April 15, 2026

2008-2009

April 15, 2027

2010-2011

April 15, 2028

2012- April 14, 2014

April 15, 2029

April 15, 2014 - present

15 years from creation

This schedule is subject to change if the underlying algorithms become more susceptible to cryptanalytic attack.

CA operators MUST apply to Mozilla for inclusion of their next generation root certificate at least 2 years before the Distrust Date above.

 

 

Jeremy

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson

Sent: Monday, September 19, 2022 11:44 AM
To: Li-Chun CHEN <lcchen...@gmail.com>
Cc: dev-secur...@mozilla.org; Filippo Valsorda <fil...@ml.filippo.io>; jespe...@gmail.com <jespe...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Roman Fischer

unread,
Sep 22, 2022, 10:51:19 AM (8 days ago) Sep 22
to dev-secur...@mozilla.org, Compliance

Dear Ben,

 

SwissSign supports Jeremy’s suggestion. Due to the longer life-time of S/MIME certificates, we would welcome a later distrust for S/MIME than for TLS.

 

Kind regards
Roman

Li-Chun CHEN

unread,
Sep 25, 2022, 12:04:15 PM (5 days ago) Sep 25
to dev-secur...@mozilla.org, Li-Chun CHEN, Filippo Valsorda, dev-secur...@mozilla.org, bwi...@mozilla.com, jespe...@gmail.com

Dear Ben,


1.     Would you mind looking at https://www.gizchina.com/2022/04/12/android-12-has-only-2-6-of-users-while-android-11-is-far-ahead/?  

    ANDROID 12 HAS ONLY 2.6% OF USERS WHILE ANDROID 11 IS FAR AHEAD in April of 2022 by Uptodown. There is a figure in above link from a survey conducted by Uptodown, a 130 million user strong alternative store to Google Play. In fact, the operating system ranks fifth among the most popular OSs. Unsurprisingly, Android 11 takes first place with 29.5% of users. The latter is followed by Android 10 (25.2%), then by Android 9 (11.5%), then by Oreo, version 8.1 of Android (11%). As mentioned above, these results are not unusual. It is now customary that versions prior to the most recent remain more popular than this one. This was particularly the case with Android 11 in 2021, which remained behind Android 10 for a long time even though a quarter of users had already adopted it.

 

2.     Please see https://9to5google.com/2022/08/12/android-12-distribution-numbers/ the news in August. Android 12 is running on 13.3% of all devices ahead of Android 13 launch. Android 11 is now at 27% from 23.8% in May. It remains the most-used version of Android today, with Android 10 following at 22.3%. Android 9 Pie is still at 14.5% and four years later still beats the latest stable release.  So the "Android Fragmentation" is a big problem.

   .

3.     Please also see https://www.gizchina.com/2022/08/15/android-12-is-installed-only-on-13-of-smartphones/

 " At the beginning of August, therefore, Android 12 was installed on 13.3% of compatible devices. Currently, Android 11 is available on 27% of compatible devices.”

 

“The truth is that even earlier versions are more popular than Android 12. So, Android 10 peaks at 22.3% installs, while Android 9 is also above it with 14.5% installs. However, this is not really surprising. Indeed, the latest versions of the operating system traditionally lag behind their predecessors."

 

“Thus, last April, Android 12 was running only on 2.6% of devices. Even though it had already been several months since its official launch had passed. These figures are due to two things. First, if the latest Android updates are available directly on Pixels, this is not necessarily the case on smartphones from other manufacturers, which sometimes have to wait several months before being able to offer them to their users with their own overlay.

 

“Added to this is the reluctance of many users, many of whom keep their smartphone for several years, for fear of experiencing bugs or slowdowns in their device by installing the latest version. Thus, the delay of Android 12 compared to its predecessors was predictable, and its rise in just a few months is on the contrary very encouraging for the future, especially at the dawn of the arrival of Android 13.”

 

Note that my colleagues who have Android 12 and 10 do not receive any upgrading message from manufacturers of their mobile phones. It is because Android's CA Trust List is distributed by smart phone's manufacturers via firmware upgrading. But my colleagues don’t use Google pixel phone to get newer Android 13.

 

    Above three points are the cases of “Android Fragmentation” problem.

 

4.    HongkongPost CA’s post said “Our several major subscribers’ of public services have recently completed research among mobile device users in Hong Kong.  It revealed that usage of the old Android devices version 10 or below (not yet pre-loaded with Root CA3) could only drop to below 5% for the Hong Kong mobile users at least after 6 years, taking into account that low-income families would slowly replace their old mobile devices.”  Hongkong Post CA used Root CA1 RSA2048 with SHA-1 2003 to cross-sign Root CA3 and extended the expiration date to 2029 for Android device users on July 27, 2022. Chunghwa Telecom's new Root CA HiPKI RCA-G1 will be pre-load in Android 13 announced on August 15, 2022. I am afraid we will face a more serious situation than Hongkong Post CA. We will face a substantial number of Taiwan resident using Android 12 or below version around 2022-2025. They may not upgrade their Android.

      To comply with Mozilla’s proposal, Chunghwa Telecom will begin transition the subscriber chained up to ePKI Root CA to HiPKI RCA-G1 (setup new subordinate CAs under HiPKI RCA-G1 first). To solve above Android’s compatibility problem, we had better suggest our PMA to allow us to use our old root CA-ePKI Root CA to cross-sign HiPKI RCA-G1. I see you extend the distrust date from April 15, 2024 to April 15, 2025. The schedule is still tight. Android’s CA trust list is the downstream of the Mozilla’s CAs’ inclusion. It means that a new Root CA will be in Android’s CA list after Mozilla’s approve of that new Root CA in Mozilla root store. What about the mechanism of removing an old Root CA by Android? Will Android remove the pre-2006 root CAs after April 15, 2025? I doubt maybe in the summer or autumn of 2025, Android will release their version to remove ePKI Root CA. But there are still lots of persons use Android 12 or below version. There will be a critical problem about the compatibility of Android. 

       In conclusion, I suggest Mozilla could extend the distrust date of affected pre-2006 Root CA dates on April 15, 2026 to solve the “Android Fragmentation” problem. Thank you.


Regards,

             Li-Chun


Li-Chun CHEN 在 2022年9月14日 星期三晚上8:11:47 [UTC+8] 的信中寫道:

Jeffrey Walton

unread,
Sep 25, 2022, 2:58:45 PM (5 days ago) Sep 25
to Ben Wilson, Li-Chun CHEN, dev-secur...@mozilla.org, Filippo Valsorda, jespe...@gmail.com
On Mon, Sep 19, 2022 at 1:44 PM Ben Wilson <bwi...@mozilla.com> wrote:
Here is another option (deleting the other MRSP language previously proposed):

Section 7.4 “Root CA Life Cycles” 

Root CA certificates included in the Mozilla root store will be distrusted when their CA key material is over 15 years old. The date of CA key material generation SHALL be determined by reference to the auditor’s key generation ceremony report. For key material generated before July 1, 2012, Mozilla will assume that the key material was generated on the “Valid From” date in the root CA certificate. For transition purposes, root CA certificates in the Mozilla root store will be distrusted according to the following schedule:  

Key Material Created

Distrust Date

Before January 1, 2006

April 15, 2025

2006-2007

April 15, 2026

2008-2009

April 15, 2027

2010-2011

April 15, 2028

2012- April 14, 2014

April 15, 2029

April 15, 2014 - present

15 years from creation

This schedule is subject to change if the underlying algorithms become more susceptible to cryptanalytic attack.

CA operators MUST apply to Mozilla for inclusion of their next generation root certificate at least 2 years before the Distrust Date above.

Thoughts?

I think "cryptanalytic attack" may be a bit too narrow. I think you should consider widening the spectrum of attacks.

What if unexpected advancements in hardware make it feasible to attack a key using existing algorithms? Or, what if the cost of power drops significantly so that powering the hardware is no longer a concern?

Jeff
Reply all
Reply to author
Forward
0 new messages