DigiCert: Threat of legal action to stifle Bugzilla discourse

Background: Revocation Delays and TRO

• DigiCert has repeatedly missed CA/Browser Forum Baseline Requirements (BR) revocation deadlines:
  • A “business category capitalization” bug (revocation required within 5 days) where DigiCert delayed for select customers.
  • A more serious CNAME validation bug: missing the leading underscore in DNS challenges, breaking an important safety assumption for multi-tenant DNS and hosting providers. BRs require revocation within 24 hours.
• In the CNAME case, a customer (Alegeus) obtained a US temporary restraining order (TRO) blocking revocation of ~70 of ~84k affected certificates.
• DigiCert then delayed revocation for all affected certs for ~5 days, not just the ~70 under the TRO. Many commenters see this as the core violation.

Legal Threat Against Bugzilla Discourse

• Sectigo’s representative pressed DigiCert hard in Bugzilla about:
  • Failing to revoke all non‑TRO certs on time.
  • Not visibly contesting the TRO or clarifying contract language.
• DigiCert’s outside counsel sent a formal letter threatening potential legal action over those Bugzilla comments, asking for clarifications and assurances.
• Later Bugzilla statements from DigiCert claiming they hadn’t used legal as a “shield” are viewed by many as contradicted by this letter; this triggered the new Bugzilla bug and the HN thread.

How Serious Is the Incident?

• One side: underscore omission is “epic” because it undermines a well-known defense for dynamic DNS / hosted subdomain platforms; by rule, any BR non‑compliance must trigger fast revocation to keep CAs honest.
• Other side: practical exploitation seems unlikely in this case; revoking tens of thousands of certs for what looks like a low‑impact implementation bug feels disproportionate and costly.

Sanctions and “Too Big to Fail”

• Some argue DigiCert’s pattern (revocation delays, TRO handling, legal threats) should lead to distrust and root removal.
• Others say immediate full distrust would break many sites (including major ones) and hurt bystanders; a more realistic precedent is:
  • Stop trusting new DigiCert-issued certs after a date.
  • Let existing certs expire naturally, as done with Symantec and others.
• There is debate whether such a move would erode trust in centralized PKI or instead demonstrate accountability.

Courts vs. PKI Rules

• Several participants stress that courts can and do override private contracts; a TRO can legally bar revocation even if contracts say otherwise.
• Critics argue DigiCert:
  • Should have revoked all non‑TRO certificates within 24 hours.
  • Should have contested the TRO more aggressively and/or dropped the customer afterward.
• Defenders note courts move slowly; working with the customer to vacate the TRO in 3–5 days may have been the fastest practical path.
• Some propose CAB Forum policies to:
  • Treat use of TROs as evidence a customer is incompatible with public PKI, leading all CAs to refuse them in future.
  • Make strong, automatic sanctions against CAs that delay revocation regardless of local legal pressure, so future CAs can point to that when opposing TROs.

Governance and Technical Reform Ideas

• Suggested mitigations and improvements:
  • “Future-dated” revocations that are published immediately but become effective later, to satisfy BR timelines while allowing migration time (others think courts would dislike this).
  • Multi‑CA or quorum-based revocation mechanisms so that other CAs can revoke when the issuing CA is blocked (possibly across jurisdictions).
  • Wider support for name constraints to limit CAs’ scope and reduce blast radius, and to allow safer enterprise/private CAs.
  • Better contract language and clear customer onboarding about strict revocation timelines and the impossibility of extensions.

Assessment of DigiCert’s Conduct

• Critical view:
  • DigiCert has a pattern of bending BR timelines to placate “special” customers, contrary to both BRs and its own published policies (e.g., on key pinning).
  • Using a TRO affecting ~70 certs to delay revocation of ~80k+ looks like opportunistic cover.
  • The legal threat against a competitor’s Bugzilla comments is seen as chilling open disclosure and discussion, which is especially problematic for a CA.
• Sympathetic view:
  • Bugs and process failures happen even at large CAs; DigiCert disclosed, investigated, and ultimately revoked.
  • The practical security delta between 24h and ~120h is seen by some as small compared to the operational risk for critical services; strict rules may be overly rigid.
  • The legal letter is framed as standard defensive lawyering rather than an attempt to silence legitimate criticism.

Broader Reflections on Web PKI

• Some commenters see the drama as evidence the ecosystem “works as intended”: public bugs, harsh scrutiny, and real business risk for misbehaving CAs.
• Others worry about:
  • Enormous effort spent on edge‑case rule violations (e.g., capitalization) vs. more impactful security work.
  • Power concentration in a few browser vendors who control root stores and also operate their own CAs.
• There is widespread agreement that CAs must be held to strict, predictable standards; disagreement centers on how strictly to apply them, how to handle legal conflicts, and what penalties are proportionate for a CA of DigiCert’s size.