[INFORMATIONAL] Upcoming change for Entrust CAs included in the Chrome Root Store

16,938 views
Skip to first unread message

Ryan Dickson

unread,
Jun 27, 2024, 1:19:28 PMJun 27
to public, chrome-root-program

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.  


Over the past 6 months, publicly disclosed incident reports highlighted a pattern of concerning behaviors by Entrust that fell short of the above expectations, and has eroded confidence in its competence, reliability, and integrity as a publicly-trusted CA Owner.


These concerning behaviors include, but are not limited to:

  • Numerous recent violations of the CA/Browser Forum TLS Baseline Requirements (e.g., [1], [2], and [3]), which in some cases were willful (e.g., [4], [5], and [6]).

  • Untimely and often incomplete incident reporting (e.g., [7], [8], and [9]).

  • A failure to demonstrate an understanding of the root causes of an incident and a lack of a substantive commitment and timeline to changes that clearly and persuasively address the root cause(s) (e.g., [10], [11], and [12]).

  • A failure to adopt industry requirements and standards as they became required (e.g., [13], [14], and [15]).

  • A failure to design error-proof and/or compliant certificate issuance systems and corresponding processes (e.g., [16], [17], and [18]).

  • A failure to uphold commitments made in policy and in response to Web PKI incidents (e.g., [19], [20], [21], [22], [23], and [24]).

  • A failure to understand incident reporting expectations with negligible, if any, improvement over time, especially while evaluating the complete set of incident report disclosures available in Bugzilla (e.g., [25], [26], [27], and [28]).

  • A failure to accept accountability or responsibility for its failures, often appearing to instead blame external forces for its compliance failures (e.g., [29], [30], [31], and [32]).

  • A failure to convey assurance of appropriate resourcing and an understanding of ecosystem requirements and expectations (e.g., [33], [34], [35], and [36]).


These concerning behaviors are further amplified because of:

  • Their collective impact when considered in aggregate. 

  • A 6+ year history of similar responses to past incidents demonstrates these behaviors are both systemic and persistent.


We have been closely following the discussions in the MDSP community regarding Entrust’s compliance failures. Despite being given a clear opportunity to thoroughly and satisfactorily address these issues through an initial report, Entrust’s response failed to meet our and the community’s expectations. When provided with yet another chance to rise to the expected level of a public CA Owner, the subsequent report, although superficially improved, still does not offer substantive, convincing evidence of meaningful change.


Upon careful review of both reports and considering ongoing incidents, which in some cases demonstrate contradictory behavior and opinions from those described in the updated report, we’re unable to find significant deviation from Entrust’s past failed commitments. It is our opinion that the recent commitments do not offer sufficient reason to believe they will result in different outcomes, and the promises made are reminiscent of those from the past, which did not lead to the required improvements.


In response to the above concerns and to preserve the integrity of the Web PKI ecosystem, Chrome will take the following actions. 


Upcoming change in Chrome 127 and higher:


This approach attempts to minimize disruption to existing subscribers using a recently announced Chrome feature to remove default trust based on the SCTs in certificates.  A recently published Google Security Blog post includes additional information for affected subscribers, to include instructions for testing the impact of the described change before it takes effect.


Should a Chrome user or enterprise explicitly trust any of the above certificates on a platform and version of Chrome relying on the Chrome Root Store (e.g., explicit trust is conveyed through a Windows Group Policy Object), the SCT-based constraints described above will be overridden and certificates will function as they do today.  


Until Entrust’s CA certificates are no longer included in the latest available version of the Chrome Root Store, we expect Entrust’s continued adherence to the Chrome Root Program Policy. Failure to do so may result in an accelerated removal timeline and/or additional restrictions.


Our decision is based on a consistent pattern of unmet commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports over the past six years. While our decision is firm and one we consider reasonable given the potential for harm a public CA poses to the Internet ecosystem, we encourage Entrust to remain committed to the principles described in their latest report and to demonstrate genuine change. By doing so, they may have the opportunity to regain the trust required to serve as a public CA in the future.


As we do with all CA Owners included in the Chrome Root Store, we will continue to use tools available to us, including Chrome’s internal PKI Monitoring solution, to measure and evaluate ongoing compliance objectives and protect Chrome’s users.


Thank you.


-Ryan, on behalf of the Chrome Root Program

Kurt Seifried

unread,
Jun 27, 2024, 4:20:20 PMJun 27
to Ryan Dickson, public, chrome-root-program
Question: what about CN = Entrust Verified Mark Root Certification Authority - VMCR1 which is used for BIMI logos for example and supported in Gmail? Will Gmail be removing support for Entrust based VMC certificates and thus BIMI logos done via Entrust?

--
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 public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADEW5O-E%2Bf4Rv3HBDq4AyX7B2JxDwcFuiBKg3L9wkvfBedbkAA%40mail.gmail.com.


--
Kurt Seifried (He/Him)
ku...@seifried.org

Julien Duplant

unread,
Jun 28, 2024, 4:53:29 PMJun 28
to CCADB Public, Kurt Seifried, public, chrome-root-program, Ryan Dickson
Hi, Gmail Security here. We're currently working internally to assess the situation, with the intent of choosing a path that takes into account the relevant use cases in Gmail while upholding the safety and security of our users. We look forward to sharing more information in the coming weeks.

Hanno Böck

unread,
Jul 5, 2024, 3:58:59 PM (8 days ago) Jul 5
to 'Kurt Seifried' via CCADB Public, Kurt Seifried, Ryan Dickson, chrome-root-program
Hi,

On Thu, 27 Jun 2024 14:19:40 -0600
"'Kurt Seifried' via CCADB Public" <pub...@ccadb.org> wrote:

> Question: what about CN = Entrust Verified Mark Root Certification
> Authority - VMCR1 which is used for BIMI logos for example and
> supported in Gmail? Will Gmail be removing support for Entrust based
> VMC certificates and thus BIMI logos done via Entrust?

In this context, possibly interesting: I had recently discovered that
many VMCs issued by Entrust were not compliant with the BIMI SVG
profile. I had made that public on the IETF BIMI list:
https://mailarchive.ietf.org/arch/msg/bimi/xzYRH72V2HE9xeUfXK_zUgYSI7k/

Entrust handled the revocation reasonably well, but of course,
it raises questions how this could happen in the first place.
(I was more disappointed with Google's/GMail's reaction, or rather,
non-reaction)

--
Hanno Böck - Independent security researcher
https://itsec.hboeck.de/

Wayne

unread,
Jul 5, 2024, 4:09:40 PM (8 days ago) Jul 5
to CCADB Public
Hanno you downplay your own research. In particular when 16 years of CVE-2008-0166 Debian OpenSSL Bug was published I did take note of how long it took until the DKIM keys were removed, and it was longer than 24 hours. 2024-05-13 15:00 UTC was when it was removed from DNS that I saw - at least 32 hours after that post was made.

I presume you had direct contact with Entrust prior to that publication as well? How long did you notice it took them to handle that known-compromised key?
Reply all
Reply to author
Forward
0 new messages