[INFORMATIONAL] Upcoming change for GLOBALTRUST 2020 in the Chrome Root Store

3,178 views
Skip to first unread message

Chris Clements

unread,
May 24, 2024, 9:19:59 AMMay 24
to public

All,


The Chrome Root Program Policy states that CA certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion. It also describes many of the factors we consider significant when CA Owners disclose and respond to incidents. When things don’t go right, we expect CA Owners to commit to meaningful and demonstrable change resulting in evidenced continuous improvement.  


On numerous instances over the last three years, e-commerce monitoring GmbH fell short of the above expectations (e.g., [1],[2],[3],[4],[5],[6],[7],[8]). In light of this, we have reached the conclusion that the GLOBALTRUST 2020 certificates suffer from a loss of integrity and action is required from the perspective of ensuring web security for Chrome users. To safeguard Chrome’s users, we are taking the following action. 


Upcoming change in Chrome 124 and higher:

  • TLS server authentication certificates validating to GLOBALTRUST 2020 whose earliest Signed Certificate Timestamp (SCT) is dated after June 30, 2024, will no longer be trusted by default.
  • TLS server authentication certificates validating to GLOBALTRUST 2020 whose earliest SCT is on or before June 30, 2024, will be unaffected by this change. 

This approach attempts to minimize disruption to existing e-commerce monitoring GmbH subscribers, using a new Chrome feature to remove default trust based on the SCTs in certificates.


Thank you

-Chris, on behalf of the Chrome Root Program


Andrew Ayer

unread,
May 24, 2024, 11:53:33 AMMay 24
to Chris Clements, 'Chris Clements' via CCADB Public
Hi Chris,

It's excellent to see action being taken against this unsafe CA.

Regarding SCT-based enforcement, I have a couple questions:

1. Are SCTs from any log accepted, or only logs that are
Qualified/Usable/Readonly?

2. I'm curious if you or anyone else is aware of efforts to audit
CT log entries for backdated timestamps? Since backdated timestamps
have never been security-critical before now, SSLMate's monitor does
not currently do any such auditing, and will not detect an SCT with a
backdated timestamp as long as the log entry has been incorporated by
the time the SCT is observed. I will be adding some checks as soon as
possible, and I'm wondering if anyone has ideas for how it should
work. (My current idea is to keep track of the log's largest entry
timestamp, and raise an error if a subsequent entry is found with a
timestamp that is earlier than the largest timestamp minus the MMD.)

Regards,
Andrew

Chris Clements

unread,
May 28, 2024, 10:45:09 AMMay 28
to Andrew Ayer, 'Chris Clements' via CCADB Public

Hi Andrew,


1. Are SCTs from any log accepted, or only logs that are Qualified/Usable/Readonly?

The latter. We’re relying only on SCTs from logs considered trusted in Chrome (i.e., Qualified/Usable/Readonly).


2. I'm curious if you or anyone else is aware of efforts to audit CT log entries for backdated timestamps?

We’re not aware of any existing efforts to actively detect backdated timestamps. It might be worth also exploring this question with ct-p...@chromium.org.


Thank you

-Chris


e-commerce monitoring

unread,
Jun 14, 2024, 11:46:37 AM (12 days ago) Jun 14
to CCADB Public, Chris Clements, 'Chris Clements' via CCADB Public, Andrew Ayer
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 c...@globaltrust.eu
Reply all
Reply to author
Forward
0 new messages