[INFORMATIONAL] Upcoming change for Entrust CAs included in the Chrome Root Store
Ryan Dickson
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:
TLS server authentication certificates validating to the following Entrust roots whose earliest Signed Certificate Timestamp (SCT) is dated after October 31, 2024 (GMT), will no longer be trusted by default.
TLS server authentication certificates validating to the above set of roots whose earliest SCT is on or before October 31, 2024 (GMT), will be unaffected by this change.
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
--
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.
ku...@seifried.org
