Dear Ryan, Thank you for bringing up the topic of the multiple anchors.
I'm wondering if Chrome and Firefox have implemented the feature to automatically look up the trust anchor. From my tests (specifically, removing AAA Certificate Services locally), it seems that Chrome can perform this look-up, but Firefox cannot. However, I'm not entirely certain. This case is far more complex than a typical scenario involving cross-signing between an Old Root and a Modern Root. AAA Certificate Services doesn't have a cross-signing certificate with SSL.com TLS ECC Root CA 2022. If there were a cross-signing relationship, things would be much simpler. I'm quite sure it wouldn't impact trust, and there would be no need for further discussion. But the subscriber hierarchy of Cloudflare TLS Issuing ECC CA 1's moden root SSL.com TLS ECC Root CA 2022, is not cross-signed with AAA Certificate Services. So, if AAA Certificate Services is removed, the ability to automatically look up the trust anchor hierarchy becomes crucial for Cloudflare and its customers. In few days to replace 12,435,053 sites certificate configuration, It should be a disaster. Thank you. Ara On Thursday, April 10, 2025 at 1:15:21 PM UTC+8 Dimitris Zacharopoulos wrote: > 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 addi > tional 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 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/1057e65f-8768-4431-9889-a4eac1cf1747n%40mozilla.org.
