Summary

  • CA/Browser Forum pull request 622 remains an open Draft Ballot SC-XX. It has not been assigned a final ballot number, voted, cleared through IPR review or made effective.
  • The current TLS Baseline Requirements measure the period to published revocation from receipt of a Certificate Problem Report or related notice. The proposal would first give a CA 24 hours to decide whether a report is actionable, then start the applicable revocation period from that decision.
  • Actionability is an intake threshold, not a finding that the CA violated a rule. The frozen draft asks for a valid identifier for at least one time-valid, unrevoked certificate plus a described policy violation or revocation reason.
  • The same actionability timestamp starts a 120-hour evaluation of all other time-valid, unrevoked certificates issued by the CA. Any additional affected certificate gets a separate clock from the time it is first identified.
  • The draft would also define Revoked in observable terms: every applicable CRL and OCSP location declared in the certificate must expose the revoked state to relying parties. That is stronger than an unseen database flag, though it does not guarantee that every cache changes simultaneously.
  • A privacy-bounded revocation receipt should join official-channel receipt, actionability, substantive finding, population expansion, reason-specific deadline and status publication. It can expose times, state codes and counts without publishing report bodies, compromised keys or subscriber data.

One incident enters; several clocks leave

A certificate problem report can arrive as a deceptively small object: one email, one form submission, one serial number, perhaps one proof that a private key or validation method should no longer be trusted. The operational consequence may be much larger. One bad certificate can reveal a shared issuance defect. One compromised key may occur in more than one certificate. A validation mistake can reach a population that the reporter cannot enumerate.

Pull request 622 tries to turn that messy intake into a clearer sequence. A CA would have 24 hours after receiving a Certificate Problem Report to decide whether it is actionable. If it is, the CA would have another 24 hours to report findings to a reachable reporter. The reason-specific revocation period would run from the actionability determination. A separate 120-hour interval would require the CA to evaluate every other time-valid, unrevoked certificate it issued for the same non-compliance. When the scan finds another affected certificate, the applicable revocation period for that certificate would run from its first identification.

This is not one clock. It is a chain of clocks, and each handoff changes what must be proved.

The current version 2.2.9 takes a simpler route. It requires a preliminary report within 24 hours after receipt and says the period from receipt of a Certificate Problem Report or revocation-related notice to published revocation must not exceed the deadline in section 4.9.1.1. Those deadlines are not uniform. Certain events, including evidence of private-key compromise or unreliable domain validation, require revocation within 24 hours. Other listed circumstances carry a 24-hour SHOULD and a five-day MUST. A useful record therefore needs both the trigger time and the reason class.

The proposal moves the outer start from receipt to actionability. Its own rationale presents that interval as a benefit: CAs gain a defined window to establish that a report contains enough information before the revocation clock applies. That can be sensible. A deadline attached to an unidentified certificate or an unintelligible allegation is not necessarily safer. But once the classification changes the compliance clock, it stops being mere inbox housekeeping.

Actionable does not mean proved

The draft’s threshold is deliberately modest. The report must contain at least one valid identifier for a time-valid, unrevoked certificate issued by the CA. Serial numbers must be supported; SHA-256 fingerprints of certificates or precertificates are a SHOULD. The report must also say how the certificate violates the Baseline Requirements or the CA’s policy, or state a reason for revocation such as key compromise.

Nothing in that test requires the reporter to win the argument. A report can be actionable and wrong. It can identify one real certificate, cite a real clause and still misunderstand the facts. It can be actionable while the CA needs days to establish the affected population. Comments on the pull request repeatedly distinguish classification from a finding of non-compliance and from completion of every remedy.

That distinction protects both sides. A reporter should not acquire the power to order revocation merely by filling required fields. A CA should not be able to postpone the clock by treating “actionable” as a synonym for “we agree.” The proposed words “is considered actionable if it includes” point toward an input test, not an outcome test.

The intake channel complicates the boundary. The proposal requires clear instructions in section 1.5.2 of the CA’s Certification Practice Statement and recommends an accessible page, FAQ or knowledge-base article. A CA may prevent non-actionable form submissions, but it must be able to receive actionable reports. Reviewers debated whether a private key, domain name, serial number or fingerprint should satisfy a form; whether email should remain mandatory; and what happens when a report is sent directly to an arbitrary employee.

Those comments are not rules. They do expose a design fact: receipt is meaningful only when the official channel is knowable. A key emailed to a human-resources employee cannot reasonably put that employee on a 24-hour technical-response clock. A security form that silently rejects the only evidence a reporter can supply is not a meaningful channel either. The receipt should therefore name the channel and the version of the public instructions that governed it.

The draft makes the stop event testable

The other half of the proposal is unusually concrete. It would add a definition of Revoked. If a certificate contains a CRL Distribution Point URI, a CRL available there must contain the certificate serial number. If it contains an Authority Information Access OCSP URI, an OCSP request to that location for the serial must return certStatus equal to revoked.

That language answers a question that has remained open in servercert issue 252 since 2021. Is revocation the moment an operator changes a database field? Is it the signing of a new CRL or OCSP response? Is it publication at an origin server? Or is it the point at which relying parties can retrieve the changed status through the distribution systems named by the certificate?

An internal bit is not enough for an external trust decision. A signed object that never leaves the origin is not enough either. The proposed definition locates completion at the interface a relying party can actually query. If both status mechanisms are declared, the natural reading is that both applicable conditions must be met.

That does not make distribution instantaneous. The issue discussion records the difficulty of purging or refreshing content across CDNs. Caches can expose different views for a bounded period. An on-demand OCSP responder may generate the relevant response only when queried. The draft’s endpoint test is therefore better understood as an observable completion condition, not a promise that every device in the world sees the same answer at the same millisecond.

The asymmetry is now visible. The stop can be probed outside the CA. The start—the actionability determination—exists first inside it.

The 120-hour scan creates a second population

The strongest addition may be the population rule. Within 120 hours of actionability, the CA would have to evaluate all of its time-valid, unrevoked certificates for additional instances of the reported non-compliance. The reporter does not have to enumerate the full population. One certificate can make the report actionable; the CA, which controls issuance data and implementation history, must look for siblings.

The DigiCert CNAME validation incident shows why that matters without proving that the draft would have prevented it. The incident record says a third party reported a validation concern while withholding known serial numbers. DigiCert’s later report identified failure to take reports without serial numbers seriously as one root cause. It also reported 83,267 valid certificates issued through the affected method at the time of the full report. The initial clue and the affected population were radically different objects.

A rule that required the outsider to list every affected certificate would reverse the information advantage. Reporters often see the symptom. CAs hold issuance logs, validation methods, account relationships and code-deployment history. The draft’s one-certificate threshold plus CA-wide scan assigns discovery to the actor best placed to perform it.

But it also creates new clock starts. The 120-hour period begins at actionability, not receipt. Each additional affected certificate’s revocation period begins when the CA first identifies it. Without a durable trace, three questions become impossible to separate: when the scan began, when the system actually matched a certificate, and when an investigator recorded the match.

A flat statement such as “population review complete” cannot answer them. The proof needs an opening population definition, method or query version, start and completion times, number examined, number newly identified, exception classes and later corrections. It need not publish the query or the customer list. It does need to prevent a newly discovered batch from appearing as if it had never been inside the original 120-hour search surface.

Better reports should not become permission to erase weak ones

The draft is motivated partly by reporting friction. The DigiCert incident involved known serials not supplied initially. A Mozilla Bugzilla complaint about SSL.com described being redirected from email to a form and uncertainty over the form’s “thumbprint” input; that bug was ultimately resolved INVALID. A separate GoDaddy thread described an official address rejecting archive attachments that contained compromised-key material; that issue was resolved FIXED.

These records do not establish one universal channel design. Email attachments can be filtered for defensible security reasons. Forms can reject spam and unrelated support questions. A cleartext private key requires exceptional handling. A reporter may be mistaken. The proposal is right not to turn every message into a revocation order.

The danger lies elsewhere: a quality threshold can become a disappearance mechanism. If a report lacks one field, the frozen draft generally requires a response within 24 hours after the non-actionable determination, asking for what is missing, when contact details exist. If the reporter later supplies the missing material, the receipt of that material becomes the basis for later timelines.

That transition should remain one case, not two unrelated inbox items. A report identifier should survive the movement from received to non-actionable to supplemented to actionable. Otherwise a CA can satisfy each local step while losing the elapsed journey. A reporter sends a detailed allegation on Monday, supplies a serial on Friday, and the public record begins on Friday as if Monday never happened. The revocation deadline may legitimately start on Friday under the proposal. The history should still show why.

A revocation receipt can stay narrow

The needed artifact is not a public dump of incident evidence. It is a join across the states that the draft already creates.

State Minimum receipt
Official intake Channel, public-instruction version, receipt time and a privacy-preserving report identifier
Initial classification Actionability decision time, required inputs present or missing, and a bounded reason code
Substantive finding Violation or revocation-reason class, explicitly separate from actionability
Initial certificate set Count, protected identifiers and applicable 24-hour or five-day deadline class
Population evaluation Scope, method version, start, completion, examined count, newly affected count and exceptions
Additional discoveries First-identification time and deadline class for each protected item or aggregate cohort
Publication Each applicable CRL/OCSP location and first successful revoked observation
Residual state Propagation exceptions, subscriber coordination, corrections and owner of the next action

The public layer can disclose timestamps, counts and state codes. Certificate identifiers can remain hashed or delayed when early disclosure would harm subscribers or an investigation. Cleartext private keys, report bodies, account records, internal detection queries and security-sensitive form controls should not be public. An auditor or root programme can inspect the protected layer when public detail would be unsafe.

This is where Lu Heng’s reality-layer distinction is useful in a bounded way. It is not Web PKI doctrine and does not decide CA/B Forum policy. It supplies a discipline: the name of a state should be joined to the executable event that gives the state consequence. Actionable changes the clock. Revoked changes what relying parties may accept. Those labels deserve timestamps and observations, not mythology.

Draft dates are not effective dates

At the research cutoff, pull request 622 was open. Its title still said SC-XX. The latest published SCWG minutes available on the Forum site placed the work under Draft Ballots and said the drafter intended to address an outstanding comment before moving it forward. The frozen branch carried a proposed 15 September 2026 date, but it was based on a version 2.2.2 snapshot while current main was version 2.2.9.

The date is therefore a field to repair and monitor, not an obligation. The checked evidence does not show a formal discussion period, ballot endorsers, a voting result, IPR review, a merged guideline or root-program enforcement. The Baseline Requirements themselves make the last boundary explicit: they are not mandatory for CAs unless and until relying-party Application Software Suppliers adopt and enforce them.

This does not reduce the draft’s importance. It makes accurate state language essential. An open pull request can improve through review. A ballot can change dates and merge current main. A final guideline can acquire an effective date. Root programmes can then specify enforcement. Each transition answers a different question.

The proposal can expose both ends of its clock

Pull request 622 solves two real problems. It gives problem reports a minimum shape without requiring outsiders to know the entire affected population. It gives revocation a relying-party-visible terminal condition rather than an invisible administrative meaning.

Its remaining governance defect is repairable. The actor under examination creates the timestamp that starts the main clock, while the outside world can test only the end. A receipt does not have to transfer that decision to the reporter. It has to make the decision attributable.

The strongest version of the proposal would publish the official-channel receipt and actionability time, preserve supplemented-report lineage, record the population scan and bind each reason-specific deadline to the status endpoints that close it. A CA could still reject an allegation on the merits. It could still protect confidential evidence. It could still coordinate replacement to reduce collateral harm within the applicable limit.

What it could not do is let the start vanish inside the institution while presenting the externally visible end as proof that the whole interval was governed.

Evidence limits

No cited source shows that any CA has manipulated an actionability timestamp under this proposal; the proposal is not in force. No source proves that a public receipt would have prevented the DigiCert, SSL.com or GoDaddy reporting problems. The incident threads differ in facts and outcomes, and the SSL.com issue was resolved INVALID.

The frozen PR contains wording defects and an outdated branch base. It may change before formal discussion. This Article evaluates the exact head at the stated cutoff and does not predict the final ballot text. It does not claim that every CRL and OCSP cache will agree instantly, that every reporter deserves disclosure, or that actionability establishes non-compliance.

The demonstrated point is narrower. The draft creates material state transitions and makes one end of the revocation interval externally observable. A minimal record can make the other end observable enough to audit without making the report itself public.

Sources

  1. Heng Lu, “On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile”
  2. CA/Browser Forum servercert pull request 622
  3. Proposed Baseline Requirements at frozen head ef1dda7b…
  4. Current Baseline Requirements at frozen main commit 5c13e270…
  5. servercert issue 252: clarify what revocation means
  6. Mozilla Bugzilla 1910322: DigiCert CNAME validation incident
  7. Mozilla Bugzilla 1942270: SSL.com reporting-mechanism complaint
  8. Mozilla Bugzilla 1942241: GoDaddy attachment complaint
  9. SCWG meeting minutes, 13 August 2026
  10. Server Certificate Working Group Charter
  11. CA/Browser Forum Bylaws