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: [email protected] <[email protected]> On Behalf Of Ben Wilson Sent: Monday, September 19, 2022 1:44 PM To: Li-Chun CHEN <[email protected]> Cc: [email protected]; Filippo Valsorda <[email protected]>; [email protected] <[email protected]> Subject: Re: Proposed Updates to MRSP to Address Root CA Life Cycles 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 On Wed, Sep 14, 2022 at 6:11 AM Li-Chun CHEN <[email protected] <mailto:[email protected]> > wrote: 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 <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fletsencrypt.org%2F2020%2F12%2F21%2Fextending-android-compatibility.html&data=05%7C01%7Crealsky%40cht.com.tw%7C439c9225c67d469a9c6408da94fe722e%7C54eb9440cf0345fe835e61bd4ce515c8%7C0%7C0%7C637986118385180284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pyIkbMYEF4AccV%2BpqOtFLzbV3p8MjLzwmMWAotdcpq4%3D&reserved=0> " 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] 的信中寫道： 2022-09-08 00:11 GMT+02:00 Ben Wilson <[email protected] <mailto:[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 -- You received this message because you are subscribed to the Google Groups "[email protected] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZdguv3J-uBNatmg7csENQWvk%2BHNRrn41xKTzpw2JGWBQ%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZdguv3J-uBNatmg7csENQWvk%2BHNRrn41xKTzpw2JGWBQ%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/DM6PR14MB2186C0C1DBE72372F970DB47924C9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
