Dear Ben, Does firefox respect certificate's AIA Extension(Authority Information Access) like Ryan and chrome did? It is important for cloudflare customers to reduce their lose those who installed SSL.com's non-cross-signed certificates chaining to AAA Certificate Services.
Thank you. Ara On Friday, April 11, 2025 at 11:58:13 PM UTC+8 Ben Wilson wrote: > Hi Martijn, > Just one clarification regarding the current state of the transition plan: > it currently specifies distrustAfter dates for S/MIME roots. > See https://wiki.mozilla.org/CA/Root_CA_Lifecycles > We're open to input on whether any similar changes should be considered > for TLS CAs. > Also, please keep in mind that, going forward, root store programs might > aim to align on a common removal framework to give CA operators better > predictability around when their root certificates will no longer be > trusted. However, we're not there yet. > Thanks, > Ben > > On Fri, Apr 11, 2025 at 9:36 AM 'Martijn Katerbarg' via > [email protected] <[email protected]> wrote: > >> Hi Dimitris, >> >> >> >> I’m forking this to a new thread to separate from the delayed trust bit >> removal thread. >> >> >> >> >Can you please share more details about the risks you see between the >> following options, for a Root CA with a hierarchy that no longer issues new >> end-entity certificates (OCSP responder certificates excluded) and all of >> its subscriber certificates have either been revoked or expired? >> >> >> >> I want to clarify here that just because the trust bits are being removed >> from Mozilla/NSS and Chrome it doesn’t mean there won’t be some unexpired >> leaf certificates, or even new certificate issuance from the hierarchy for >> a small number of subscriber edge cases. >> >> >> >> For the sake of this discussion, I’ll leave in the middle whether these >> edge cases are good or bad. We certainly see both. I also believe the >> WebPKI is currently in a more active transformational state, one where >> proper customer education about using the right PKI at the right location >> is more important than ever. >> >> >> >> 1. Utilizing distrust notAfter/notBefore modern browser methods >> >> 2. Removal of "trust bits" >> >> 3. Removal of the Root CA entirely, especially if there are no >> "trust bits" enabled. >> >> >> >> I want to say here that we believe all three mechanisms should be >> utilized, in the correct order (frankly, the one you specified). >> >> >> >> At this moment, number 2 and 3 are utilized by Mozilla for the scheduled >> deprecations due to CA key lifetimes. The main reason for this is the >> different removal dates for SMIME and TLS. As an example for a multipurpose >> root: >> >> - 2025-04-15: TLS trust bit removal >> >> - 2028-04-15: S/MIME trust bit removal / complete Root CA >> removal. >> >> >> >> When looking at single purpose hierarchies, the direct Root CA removal >> could be the first step. >> >> >> >> We would like to advocate adding the first option at the beginning of the >> process, changing the example to: >> >> - 2024-04-15: DistrustAfter set for TLS and S/MIME >> >> - 2025-04-15: TLS trust bit removal >> >> - 2028-05-15: Complete Root CA removal >> >> >> >> We believe this approach would help significantly to make root >> deprecations smoother for CAs and Subscribers alike. >> >> What this change would essentially force is setting a single date for >> both TLS and S/MIME, after which any newly issued certificate won’t be >> trusted by Mozilla. >> >> The issue we see currently is that certificates issued at the same time >> have different trust removal dates. As an example, with our AAA Certificate >> Services Root CA: >> >> >> >> - A TLS certificate issued on 2025-01-15 for 200 days, after >> 3 months will stop being trusted. >> >> - A TLS certificate issued on 2025-02-15 for 30 days, would >> be trusted for its entire lifetime. >> >> - An S/MIME certificate issued on 2026-04-15 for 3 years, >> would have its trust removed after 2 years. >> >> - An S/MIME certificate issued on 2027-04-15 for 1 year, >> would be trusted for its entire lifetime. >> >> >> >> We believe (and have noticed in practice) that this easily leads to >> confusion, whereas having a single “DistrustAfter” date based on the >> notBefore date for all certificate types allows for more clarity. >> >> >> >> Additionally, using “DistrustAfter” also has the benefit of showing a >> non-trusted state immediately after installation of a certificate, rather >> than (for the Subscriber and Relying Parties perspective) at a random >> moment. >> >> >> >> While a CA could obviously choose to halt issuance early on a hierarchy >> to ensure all leaf certificates expire before the root removal date, that >> would no longer allow for the sorts of subscriber edge cases that I touched >> on above. >> >> >> >> Regards, >> >> Martijn >> >> >> >> *From: *'Dimitris Zacharopoulos' via [email protected] < >> [email protected]> >> *Date: *Thursday, 10 April 2025 at 07:15 >> *To: *[email protected] <[email protected]> >> *Subject: *Re: Postponement of Removal of Websites Trust Bit for ePKI >> Root CA >> >> Martijn, >> >> Can you please share more details about the risks you see between the >> following options, for a Root CA with a hierarchy that no longer issues new >> end-entity certificates (OCSP responder certificates excluded) and all of >> its subscriber certificates have either been revoked or expired? >> >> 1. Utilizing distrust notAfter/notBefore modern browser methods >> 2. Removal of "trust bits" >> 3. Removal of the Root CA entirely, especially if there are no "trust >> bits" enabled. >> >> I'm very interested to hear the ecosystem risks for each of these >> choices. It feels that the order is correct in terms of risks but I'm more >> interested to hear what you and others feel about the 3rd option. >> >> >> >> Best regards, >> >> Dimitris. >> >> >> >> On 9/4/2025 11:10 μ.μ., 'Martijn Katerbarg' via [email protected] >> wrote: >> >> All, >> >> > If Mozilla directly removes the "AAA Certificates Servies" and others, >> more than 12,435,053 websites issued by "Cloudflare TLS Issuing ECC CA 1" >> will be affected, It has bad impact on the business of CloudFlare's >> customers. >> >> > The above is what I have found out through about few minutes of >> research, based on the sites count and I think it will have a gravity >> impact. >> >> > I request the community to conduct an assessment to reduce this impact. >> >> As already pointed out by Ryan, these certificates can all be validated >> through multiple chains. >> >> With the experience we’ve gained from preparing for this root certificate >> removal, we do want to add that we believe future scheduled root >> certificate deprecations would benefit from utilizing the mechanisms for >> distrust based on notBefore (Mozilla) and SCTNotAfter (Chrome), rather than >> a hard deadline for trust bit removal. This probably warrants its own >> discussion thread though, potentially on the CCADB Public list. >> >> > Please consider avoiding the DistrustAfter strategy. It causes problems >> for tools which use Google, Mozilla (and friends) curated lists of trusted >> CAs. The tools include utilities like cURL and Wget. >> >> We don’t agree with this. The DistrustAfter mechanism is one very >> suitable for a graceful removal of trust, be it for scheduled deprecations, >> or other forms of trust removal. >> >> The tools mentioned, or more broadly, Linux distributions that build >> their ca-certificates packages based on the data available in Mozilla/NSS, >> have hopefully chosen to do so for a reason: They believe the open source >> root store that Mozilla provides fits their needs and provides the >> transparency the open source community is usually looking for. >> >> If the Mozilla root store believes the DistrustAfter mechanism is viable >> and is a better option (which we agree with in general), then the parties >> relying on the root store need to adjust to follow that guidance, or >> re-assess their needs. They should at no point be holding back innovation >> and improvements of the Mozilla root store / NSS. >> >> We’d like to remind everyone of this Mozilla blog post >> <https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/>, >> >> which mentions this wiki page >> <https://wiki.mozilla.org/CA/Additional_Trust_Changes> that discusses >> additional factors (including DistrustAfter) that application developers >> need to be aware of if they are using Mozilla’s root store. >> >> Regards, >> >> Martijn Katerbarg >> Sectigo >> >> >> >> Op woensdag 9 april 2025 om 19:08:43 UTC+2 schreef Ryan Dickson: >> >> Hi Arabella, >> >> >> >> The example provided can validate to multiple >> <https://crt.sh/?graph=15005443728&opt=nometadata> anchors. >> >> >> >> For example, an alternate path to an SSL.com root is provided below. >> >> >> >> Anchor: SSL.com TLS ECC Root CA 2022 >> <https://crt.sh/?q=c32ffd9f46f936d16c3673990959434b9ad60aafbb9e7cf33654f144cc1ba143> >> >> ---> SSL.com TLS Transit ECC CA R2 >> <https://crt.sh/?q=5d1bc399274e649e1c72697de91a54ad725088c5221cb61e17ee9c290bc42a92> >> >> ---> Cloudflare TLS Issuing ECC CA 1 >> <https://crt.sh/?q=2964fd3210ea68faa2b4a849b36243d33f74429d1b43ce019e7b154eac7759ba> >> >> ---> www.relialabtest.com >> <https://crt.sh/?q=133f15fc8303dccb6b319b65c6d9f2ff9ae1c0fea4abf2eaf70939d77240dc0a> >> >> >> >> Hope this helps! >> >> >> >> - Ryan >> >> >> >> On Wed, Apr 9, 2025 at 12:40 PM Arabella Barks <[email protected]> >> wrote: >> >> Sorry, I forgot to post one case https://www.relialabtest.com it is the >> hierarchy I mentioned. >> >> On Thursday, April 10, 2025 at 12:36:03 AM UTC+8 Arabella Barks wrote: >> >> Ben, >> >> I still suggest adopting the distrust-after. >> Among the root intermediates that Mozilla plans to remove trust, there is >> the "AAA Certificates Servies" of Sectigo CA, which is being widely issued >> and used by a subordinate CA of Cloudflare, namely "Cloudflare TLS Issuing >> ECC CA 1" (https://crt.sh/?caid=282054, and issued by "SSL.com TLS >> Transit ECC CA R2"). However, SSL.com TLS Transit ECC CA R2 is just a >> subordinate CA and not a Root. >> >> If Mozilla directly removes the "AAA Certificates Servies" and others, >> more than 12,435,053 websites issued by "Cloudflare TLS Issuing ECC CA 1" >> will be affected, It has bad impact on the business of CloudFlare's >> customers. >> The above is what I have found out through about few minutes of research, >> based on the sites count and I think it will have a gravity impact. >> >> I request the community to conduct an assessment to reduce this impact. >> >> On Thursday, April 10, 2025 at 12:10:21 AM UTC+8 Ben Wilson wrote: >> >> Thanks for your feedback. Currently, our proposed strategy for handling >> this particular issue will be to postpone processing the websites trust bit >> removal from the Chunghwa Telecom ePKI Root CA by two or three months >> (until approximately Firefox Release 141 >> <https://whattrainisitnow.com/release/?version=141>). In other words, we >> do not anticipate using the distrust-after mechanism in the present case. >> >> Thanks again, >> >> Ben >> >> >> >> On Wed, Apr 9, 2025 at 9:55 AM Jeffrey Walton <[email protected]> wrote: >> >> On Tue, Apr 1, 2025 at 11:03 AM 'Ben Wilson' via >> [email protected] <[email protected]> >> wrote: >> > >> > Per - https://bugzilla.mozilla.org/show_bug.cgi?id=1891438#c15: >> > >> > "In the interest of transparency, Mozilla received a formal request >> from Taiwan’s Ministry of Digital Affairs (MODA), dated March 15, 2025, >> requesting that we delay the removal of the “websites” trust bit for >> Chunghwa Telecom’s ePKI Root CA, which is currently scheduled to occur on >> or about April 15, 2025, in accordance with Mozilla’s Root CA Lifecycles >> Transition Schedule. >> > >> > MODA explained that the requested delay is intended to support the >> ongoing transition of government websites away from certificates issued by >> CHT’s GTLSCA-G1 subordinate CA. As we understand it, MODA is already >> implementing a short-term migration plan involving the dual issuance of >> approximately 12,000 new certificates for government websites—one from >> Chunghwa Telecom and one from Taiwan CA (TWCA)—to ensure continued >> availability of government services and minimize user disruption. >> > >> > While we have not yet finalized a decision, we are currently >> contemplating: >> > >> > Postponing the removal of the “websites” trust bit; >> > Implementing a distrust-after date; or >> > Taking other actions consistent with Mozilla Root Store Policy and >> ecosystem risk management. >> > >> > We note that: >> > >> > The ePKI Root CA uses a 4096-bit RSA key, which provides stronger >> security than other similarly aged root certificates. >> > Any extension under consideration would be strictly time-bounded (e.g., >> not to exceed August 1, 2025), reflecting a short-term accommodation, not a >> change in long-term policy direction. >> > Mozilla would retain the right to remove or revoke trust at any time, >> based on new information or evolving risk factors. >> > >> > We welcome feedback on any of these approaches." >> >> Please consider avoiding the DistrustAfter strategy. It causes >> problems for tools which use Google, Mozilla (and friends) curated >> lists of trusted CAs. The tools include utilities like cURL and Wget. >> See, for example, <https://github.com/curl/curl/issues/15547>. >> >> Jeff >> >> -- >> >> 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 visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c0794245-c1c8-417c-a40e-a7154a4720d2n%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c0794245-c1c8-417c-a40e-a7154a4720d2n%40mozilla.org?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 visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/136da9cf-e967-401c-9cc9-d2031655d605n%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/136da9cf-e967-401c-9cc9-d2031655d605n%40mozilla.org?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "[email protected]" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/uYAm_c_pfos/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c7ddab01-7145-4b87-a2c0-5532eca6675b%40it.auth.gr >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c7ddab01-7145-4b87-a2c0-5532eca6675b%40it.auth.gr?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 visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SA1PR17MB6503CA06DEF442B9389D4681E3B62%40SA1PR17MB6503.namprd17.prod.outlook.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SA1PR17MB6503CA06DEF442B9389D4681E3B62%40SA1PR17MB6503.namprd17.prod.outlook.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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f198323c-1c76-4a7b-9c96-16f5fa82e0d2n%40mozilla.org.
