The mechanism was the message
On March 23, 2017, a Google engineer posted to the blink-dev mailing list under the subject line “Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates.” The post was not a standards proposal. It was a notice of enforcement, with a schedule attached. That distinction matters more than the eventual outcome, because it tells you where authority over the WebPKI actually sits.
The post, by Ryan Sleevi, laid out three levers: a cap on the validity period of newly issued Symantec certificates at nine months or less; an incremental distrust of existing Symantec-issued certificates across a series of Chrome releases; and removal of Extended Validation status for Symantec-issued certificates for at least a year (blink-dev thread). Each lever operated on the client side. None required a CA/Browser Forum ballot. None amended the Baseline Requirements. The operative instrument was the trust store.
What the proposal actually said
The evidentiary core of the post was a claim about scope. The Chrome team said it had been investigating Symantec since January 19, and that “an initial set of reportedly 127 certificates has expanded to include at least 30,000 certificates, issued over a period spanning several years.” The post attributed the expansion to Symantec’s explanations under questioning, not to independent discovery by Google.
The post also made a structural allegation: “Symantec allowed at least four parties access to their infrastructure in a way to cause certificate issuance, did not sufficiently oversee these capabilities as required and expected, and when presented with evidence of these organizations’ failure to abide to the appropriate standard of care, failed to disclose such information in a timely manner.” That is a claim about governance of the issuance pipeline, not about any single misissued certificate.
The compatibility argument was explicit. Symantec-issued certificates had represented “more than 30% of the valid certificates by volume” in January 2015, and the post acknowledged that immediate distrust would impose costs on site operators, particularly those supporting older devices. The phased schedule was a deliberate trade: security urgency against migration time.
The schedule as a governance instrument
The distrust was not keyed to issuance date in the March proposal. It was keyed to certificate age. The mechanism, as described in the post: “gradually decreasing the ‘maximum age’ of Symantec-issued certificates over a series of releases, distrusting certificates whose validity period (the difference of notBefore to notAfter) exceeds the specified maximum.”
The proposed ladder ran from 33 months in Chrome 59 down to 9 months by Chrome 64, with a deliberate pause at Chrome 63 Stable to avoid the winter holiday production freeze. That detail is worth pausing on. A root program was scheduling trust changes around enterprise change-management calendars. That is regulator behavior, whether or not anyone used the word.
The post also stated plainly that this was a departure from normal practice: “Historically, the Google Chrome team has not used the Blink Process for Certificate Authority-related security issues… However, we are interested in exploring using this process for such changes, as it provides a greater degree of transparency and public participation.” The transparency channel was discretionary. The trust store was not.
The implementation artifact
The December 2017 Chromium commit that implemented phase one is more instructive than the proposal, because it shows what “distrusting a CA” actually means in code. The commit message states: “All new certificates issued from the legacy Symantec infrastructure – excluding those CAs above and the pre-existing independent sub-CAs – issued on or after 2017-12-01 are not trusted” (Chromium commit bd9ca31).
The exclusions are the interesting part. DigiCert Global Root G2 and G3 were “treated as indepedently operated sub-CAs, as they were CAs already trusted on Chrome and Android, despite having been recently cross-signed by the legacy Symantec infrastructure.” The DigiCert Transition RSA and ECC roots were “treated as Managed Sub-CAs, subject to the Managed Partner Infrastructure policies,” with all certificates from those roots required to be CT Qualified.
This is not a binary switch. It is a set of scoped, negotiated technical decisions about which roots inherit which obligations. The commit also notes that the changes were not included in Android WebView, where trust propagates via system updates or the Google Play Services security provider. The same policy, applied to a different client, travels through a different governance path.
The scope dispute, as a dispute
Symantec’s public response, as reported by TechTarget, rejected the 30,000 figure: “Google’s claim that we have misissued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates — not 30,000 — were identified as misissued, and they resulted in no consumer harm” (TechTarget, March 24, 2017). Symantec called Google’s actions “irresponsible” and accused it of singling out the CA.
Neither figure is a finding. Both are party assertions. What the exchange does establish is an asymmetry in the process: the root program controls the investigation, the evidence-gathering questions, and the enforcement timetable. The CA responds in public, under deadline pressure, to a schedule it did not set.
The Mozilla side of the same period shows a similar dynamic with a different tempo. TechTarget reported that Gervase Markham set a one-week deadline for Symantec responses to a list of 14 issues, then extended it to April 20 after objections about the Easter holiday (TechTarget, April 12, 2017). The deadline was a root-program instrument, not a Forum ballot.
What the Forum did, and did not, do
The CA/Browser Forum is where the Baseline Requirements are written. It is not where this enforcement happened. The retrieved record does not show a Forum ballot authorizing the Symantec distrust, and the proposal itself did not route through the Forum. The Forum minutes from June 2018 record Google’s report that “Chrome 68 distrusted the first wave of Symantec certificates according to the announced distrust plan. Chrome 70 will address the following waves” (CA/B Forum F2F 44 minutes). The Forum was the venue where the root program reported what it had already done.
The same minutes record Apple’s parallel action: “Phase 1 is in beta builds and this will distrust Symantec issued TLS server certificates issued before June 1, 2016 and after December 1, 2017. Phase 2 is coming, but no details were provided.” Apple’s phase boundaries differ from Chrome’s. The two root programs were not executing a shared plan; they were each enforcing their own trust decisions on their own schedules.
The March 2017 proposal had already flagged this divergence: “Assessing the compatibility risk with both Edge and Safari is difficult, because neither Microsoft nor Apple communicate publicly about their changes in trust prior to enacting them.” The WebPKI, in practice, is not one regulator. It is several root programs whose decisions a site operator must satisfy simultaneously, with different transparency norms.
Why the phased-by-validity design matters
The choice to distrust by certificate age rather than issuance date is a governance choice as much as a security one. It converts a trust judgment into a migration deadline that site operators can plan around. A certificate issued in 2016 with a three-year validity would survive longer than one issued in 2017 with the same validity, because the clock ran from notBefore. The schedule was published in advance, release by release, so that operators could map their renewal cycles onto it.
That is a different instrument from a revocation. Revocation is a per-certificate action, mediated by OCSP and CRLs, and it is notoriously unreliable in practice. A validity cap enforced at the client is a policy that applies to every certificate in scope, regardless of whether any revocation infrastructure cooperates. It is also harder to reverse quietly. The commit is public, the schedule is public, and the carve-outs are visible in the code.
What the case does and does not establish
It establishes that a browser root program can set and enforce trust policy for a CA without a Forum ballot, on a published schedule, with scoped technical exceptions negotiated in code. It establishes that the transparency channel for such decisions is discretionary, as the proposal itself said. It establishes that cross-browser divergence is real and that site operators bear the cost of satisfying multiple root programs.
It does not establish that the 30,000 figure was correct, or that the 127 figure was correct. It does not establish what Mozilla ultimately decided, because the Mozilla wiki page was not retrievable for this piece. It does not establish the terms or closing date of the DigiCert acquisition of Symantec’s website security business, because the DigiCert release was not retrievable. It does not establish any market outcome, revenue effect, or consumer harm finding. Those are gaps, not conclusions.
The proposal itself acknowledged the compatibility cost: site operators forced to migrate without time to research alternatives, users encountering errors, and the risk that “the error is often seen as the browser’s fault, despite it being a failure of the CA to provide the necessary level of assurance.” That is the unresolved question the case leaves behind. A root program can act as regulator. Whether it can do so while bearing the legitimacy costs of a regulator — due process, consistent evidentiary standards, and accountability for the compatibility costs it imposes — is a question the Symantec wind-down raised but did not answer.
FAQ
Did the CA/Browser Forum authorize Chrome’s distrust of Symantec?
The retrieved record does not show a Forum ballot authorizing the distrust. The March 2017 proposal was posted to blink-dev, not routed through the Forum, and the June 2018 Forum minutes record Google reporting the distrust as an accomplished fact.
How did the phased distrust work?
Chrome lowered the maximum accepted certificate age over a series of releases, distrusting Symantec-issued certificates whose validity period exceeded the cap. The proposed ladder ran from 33 months in Chrome 59 to 9 months by Chrome 64, with a pause at Chrome 63 Stable for the holiday production freeze.
What happened to DigiCert roots in the transition?
The December 2017 Chromium commit treated DigiCert Global Root G2 and G3 as independently operated sub-CAs, exempt from the Symantec-specific CT requirement, and treated the DigiCert Transition RSA and ECC roots as Managed Sub-CAs subject to Managed Partner Infrastructure policies.
Did other browsers follow the same schedule?
No. Apple’s Phase 1, as recorded in the June 2018 Forum minutes, distrusted Symantec-issued TLS server certificates issued before June 1, 2016 and after December 1, 2017, with Phase 2 to come without details provided. The phase boundaries differ from Chrome’s.