As you might know, browsers have decided to remove e-commerce monitoring GmbH (ECM) with its Root Certificate "GLOBALTRUST 2020" from their Root Programs as of June 30, 2024. Certificates issued before this date will retain their full validity.
The reasons for the removal have been comprehensively discussed Bugzilla forum. We acknowledged and accepted the decision. We have identified the shortcomings in our processes, particularly related to reaction time. Consequently, we are taking these issues very seriously and are committed to address them. An action plan is being rolled out to restructure our Certificate Authority (CA) functions. Our goal is to be included again in the Root Programs. ECM’s shareholder, AUSTRIA CARD, is committed to regains full compliance with the Browser/OS Root Store Policies. This commitment, which is strongly supported by our recently changed management, underscores our dedication to maintaining the widest compatibility and coverage. As an immediate action, and until full remediation, ECM has ceased the issuance of TLS certificates according to the CA/Browser Forum Requirements. TLS certificates will be provided solely based on Regulation (EU) No 910/2014, Annex IV, as recently amended by Regulation (EU) 2024/1183 (“QWACs”). Certificates for interoperability testing purposes are excluded from this decision. ECM, with its product lines GLOBALTRUST and TRUST2GO, is a Qualified Trust Service Provider (QTSP) according to EU eIDAS regulation and is under continuous supervision by the Austrian regulatory authority (RTR/TKK). Our activities are regularly evaluated by an accredited conformity assessment body based on numerous standards (e.g., eIDAS, ETSI), which include comprehensive logical, physical, and organizational security measures. Our goal is to rebuild trust and demonstrate our commitment to upholding the highest standards in our industry. For inquiries, please contact the Compliance & Product Management team, Attn: Mr. Daniel Zens, at [email protected] On Wednesday, June 12, 2024 at 5:30:34 PM UTC+2 Mike Shaver wrote: > Thanks, that’s good to hear. > > I think that there’s value in the thought experiment of “if Globaltrust > for some weird reason asked to be added to the root store now, with a > notBefore limit a little ways in the future and only the current trivial. > set of certs in the wild, would we allow that? does it make Firefox and the > web better for that root to be trusted that way?” > > For me the answer is “no, making those handful of certs work is not worth > the exposure”. > > If we don’t remove the root, then I think we should set the notBefore > limit to match the last cert that has already been issued. I don’t think we > want to honour any certs that GlobalSign issues over the next few weeks… > > Mike > > On Wed, Jun 12, 2024 at 10:55 AM 'Ben Wilson' via [email protected] > <[email protected]> wrote: > >> Dear Andrew and all, >> >> We understand your concerns. >> >> We are evaluating and considering your suggestions. >> >> Thanks, >> >> Ben Wilson >> >> Mozilla Root Program Manager >> On Tuesday, June 11, 2024 at 4:58:02 PM UTC-6 [email protected] wrote: >> >>> I have to echo the sentiments, and question what setting a notBefore >>> date weeks into the future signals to a non-compliant CA. If we're already >>> in agreement that trust is lost, what does this grace period provide if not >>> more room for either unintionally malicious, or actively malicious actions >>> even by a third party? Any actions that have caused a CA to get into this >>> trust state are doubtless continuing in the leadup to the final notBefore >>> day. >>> >>> Isn't this in effect a tacit agreement for a non-compliant CA to do what >>> they wish for the next few weeks, because ultimately what is going to >>> happen if they don't? What would be a root program's response is on the >>> issuance of a distrust statement a CA then quietly sells non-SCT >>> certificates for, say, interception purposes? It's a narrower window of >>> opportunity but I can see a CA who is looking to make one last grab for >>> cash on the way out abusing this system as it stands. I'm of the opinion >>> that we need to build these enforcement mechanisms defensively and presume >>> a malicious party if only for the security implications. >>> >>> I can see an argument for a few days for the CA to recognize they are no >>> longer trusted and to remove all documentation stating that their future >>> issuances would work in specific root chains. I just don't see the security >>> or integrity rationale in such a wide window, although I recognize that it >>> has previous precedent I'd echo my statements to those as well. >>> >>> - Wayne >>> >>> On Tuesday, June 11, 2024 at 10:55:29 PM UTC+1 Mike Shaver wrote: >>> >>>> I have to agree with Andrew. Continuing to trust this root and the >>>> integrity of "notBefore" on the certs it issues seems like it adds risk to >>>> Firefox and Thunderbird users without basically any value to the world. If >>>> those certificates have their key material leak, do we have any reason to >>>> believe that ECM will actually spring to life and help the subscribers? I >>>> cannot think of such a reason. >>>> >>>> IMO we should excise it cleanly, and let Mozilla's users deal with the >>>> fact that they can't access those handful of sites--if indeed they ever >>>> ever notice. >>>> >>>> Mike >>>> >>>> >>>> On Tue, 11 Jun 2024 at 15:55, Andrew Ayer <[email protected]> >>>> wrote: >>>> >>>>> On Tue, 11 Jun 2024 13:11:16 -0400 >>>>> Andrew Ayer <[email protected]> wrote: >>>>> >>>>> > If we exclude ECM's own domains, this drops down to just 36 distinct >>>>> > DNS names. >>>>> >>>>> Further analysis: of the 36 DNS names, >>>>> >>>>> 18 are serving a non-ECM certificate on port 443 >>>>> 9 are serving an ECM certificate on port 443 >>>>> 6 did not respond on port 443 >>>>> 3 are wildcard DNS names >>>>> >>>>> Regards, >>>>> Andrew >>>>> >>>>> -- >>>>> 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/20240611155511.4871da6bf1be264046b9d62d%40andrewayer.name >>>>> . >>>>> >>>> -- >> 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/5b7a138e-ce79-4b12-a620-c95584e6fa46n%40mozilla.org >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5b7a138e-ce79-4b12-a620-c95584e6fa46n%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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f1cc429a-2b7c-408a-8583-7baecdab9839n%40mozilla.org.
