Hi Kurt, FWIW, these Root CA certificates have not been accepted into the Apple Root Program.
Cheers, -Clint > On Jun 2, 2023, at 10:03 AM, 'Kurt Seifried' via CCADB Public > <[email protected]> wrote: > > I'm curious, can we get any information from the other major browser vendors > as to whether or not they are removing these certificates, and if not why > not? Thanks! > > On Fri, Jun 2, 2023 at 6:17 AM Ryan Dickson <[email protected] > <mailto:[email protected]>> wrote: >> All, >> >> We’d like to extend our appreciation to Ian Carroll for reporting this issue >> to us, and for Ian’s continued availability during the incident’s discussion >> (both here and on Bugzilla). >> >> After full consideration of the available information related to the >> vulnerabilities disclosed at https://ian.sh/etugra, including that of >> incident reports and other public responses, we have decided that in order >> to appropriately protect and safeguard Chrome users, the following e-Tugra >> Root CA certificates will be removed from the Chrome Root Store: >> >> E-Tugra Global Root CA ECC v3 >> <https://crt.sh/?q=873F4685FA7F563625252E6D36BCD7F16FC24951F264E47E1B954F4908CDCA13> >> >> E-Tugra Global Root CA RSA v3 >> <https://crt.sh/?q=EF66B0B10A3CDB9F2E3648C76BD2AF18EAD2BFE6F117655E28C4060DA1A3F4C2> >> Most Chrome users will automatically receive these updates via Component >> Updater >> <https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/README.md> >> immediately after publication of Version 11 of the Chrome Root Store >> (expected no later than June 15, 2023). In the event that a Chrome user has >> disabled Component Updater, these changes will be enabled by default >> beginning in Chrome Version 115 (stable release approximately July 18, >> 2023). No additional Chrome user action is required. >> >> We only observe test certificates chaining to the roots listed above >> (examples [1 >> <https://search.censys.io/search?resource=certificates&q=parsed.extensions.authority_key_id%3A+c75515756c8ba0e3f76f6d26bfb36a7dabad6bf9>], >> [2 >> <https://search.censys.io/search?resource=certificates&q=parsed.extensions.authority_key_id%3A+baab83568fb245a9dc59e42880a537a02748a162>], >> and [3 >> <https://search.censys.io/search?resource=certificates&q=parsed.extensions.authority_key_id%3A+c47f06cfaf010dacc54a19df51f41fc3a5a26186>]). >> Consequently, it is our understanding that there is no impact to e-Tugra >> subscribers or Chrome users as a result of this change. >> >> We may take further action, or accelerate the timeline described above, as >> additional information becomes available to us. >> >> - Ryan >> On behalf of the Chrome Root Program >> >> >> On Mon, Feb 27, 2023 at 2:12 PM 'Kurt Seifried' via >> [email protected] <mailto:[email protected]> >> <[email protected] <mailto:[email protected]>> >> wrote: >>> On Sun, Feb 26, 2023 at 2:22 AM Ryan Hurst <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>> This thread and associated bug have been silent for an >>>> uncharacteristically long time, and I am curious as to when this issue >>>> will be closed. >>>> >>>> Furthermore, I would like to understand what changes will be put into >>>> place to clarify appropriate incident handling behavior. It is important >>>> that Mozilla establishes a clear protocol for handling security incidents >>>> and communicates this effectively to all participants. >>>> >>>> I am also curious in how Mozilla will choose to interpret the facts that >>>> have been made available. The way in which this incident is handled will >>>> establish a precedent for future security incidents, and it is important >>>> that Mozilla approaches this with a clear and consistent stance. >>>> >>>> Ryan Hurst >>> >>> So my take on this is: we're still in the 2000 era of "apply to be a root >>> ca, get in by default, stay in by default", that is to say, if you have all >>> the paperwork and don't do something terrible, well you're good to go. >>> Witness: >>> >>> SERPRO issued numerous malformed/bad certificates indicating a lack of the >>> most basic controls and voluntarily withdrew their application and can >>> re-apply later. >>> >>> BJCA.cn has links to what appears to be spyware, but has said "it's fine" >>> and they have been approved: >>> >>> This is notice that I am closing public discussion and that I am >>> recommending that we approve BJCA’s inclusion request. >>> This begins a 7-day "last call" period for any final objections. >>> >>> Also no mention or suggestion of limiting them to e.g. .cn for example. >>> >>> TRUSTCOR not only crossed some lines but then publicly made statements that >>> were later found to be false, I'm guessing had they "fallen on their sword" >>> and apologized they'd still be a CA. >>> >>> Mailing list participation is another good indicator that nobody really >>> cares, the same 20-30 people are posting, on issues that affect the entire >>> world. >>> >>> The reality is that nobody really cares, nothing that bad has happened (at >>> least in the western world, ignoring the spyware and dead journalists, and >>> repression in various countries). I have a briefing on this and it boils >>> down to "if you want to be especially paranoid do what VISA does >>> (https://developer.visa.com/pages/trusted_certifying_authorities), there's >>> no point in trying to prevent bad CAs from getting in or staying in". >>> >>> >>> >>> >>>> On Monday, November 28, 2022 at 2:52:47 AM UTC-8 Peter Gutmann wrote: >>>>> Ian Carroll <[email protected] <>> writes: >>>>> >>>>> >There are many statements about M of N, HSM access, etc which do not >>>>> >appear >>>>> >to be relevant to this issue. >>>>> >>>>> >>>>> That's not specific to e-Tughra though, that's standard for CAs where what >>>>> gets audited is all the fancy security mechanisms around the CA's private >>>>> key(s) and what barely, or not at all, gets audited is the various RAs >>>>> that >>>>> pull the CA's strings. >>>>> >>>>> Years ago I saw a cartoon lampooning a certain country's defence policy >>>>> which >>>>> had lifeguard-style flags set up on a piece of open ground and a sign >>>>> between >>>>> them saying "Please attack between the flags". With CA's it'd be "please >>>>> audit between the flags". >>>>> >>>>> Not defending or criticising e-Tughra, just pointing out that this isn't >>>>> their >>>>> fault, it's How CAs Are Done. >>>>> >>>>> Peter. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> -- >>> Kurt Seifried (He/Him) >>> [email protected] <mailto:[email protected]> >>> >>> -- >>> 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/CABqVa3-JgfmFu_9H4Bic6eC2ZnKA8wSG5aewyUH06CC49CjSkA%40mail.gmail.com >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa3-JgfmFu_9H4Bic6eC2ZnKA8wSG5aewyUH06CC49CjSkA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > Kurt Seifried (He/Him) > [email protected] <mailto:[email protected]> > > -- > You received this message because you are subscribed to the Google Groups > "CCADB Public" 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/ccadb.org/d/msgid/public/CABqVa39akV6CjPTfBr8oKumv6Q%2B5Tw8%2BWCME38-fhQLx7C%3DHJQ%40mail.gmail.com > > <https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa39akV6CjPTfBr8oKumv6Q%2B5Tw8%2BWCME38-fhQLx7C%3DHJQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "CCADB Public" 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/ccadb.org/d/msgid/public/83617204-1A26-48DC-BEFC-60C0F5D0A50B%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
