A vote, not a manifesto
On April 11, 2025, the CA/Browser Forum adopted Ballot SC081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods. The tally is the first artifact worth reading. Certificate Issuers: 30 votes, 25 yes, 0 no, 5 abstentions — Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, and TWCA. Certificate Consumers: 4 votes, 4 yes, 0 no, 0 abstentions — Apple, Google, Microsoft, Mozilla. The quorum was 16, and the bylaws thresholds were met. The motion was proposed by Clint Wilson of Apple and endorsed by Nick France of Sectigo, Ryan Dickson of Google Chrome, and Ben Wilson of Mozilla.
That is the whole political fact of the ballot, and it is more interesting than the headline number. The only category with unanimous, no-abstention support was the four organizations that do not issue certificates. The category that must implement the schedule produced five abstentions and no recorded no votes. Abstention is not opposition, and nothing in the tally tells us why any issuer abstained. But it is the observable issuer posture, and it is worth holding next to the schedule itself.
What the ballot actually changes
The ballot text is explicit about the direction and the dates. It expands Section 6.3.2 to schedule reductions in maximum Public TLS certificate validity, and expands Section 4.2.1 to schedule reductions in validation-data reuse. The eventual maximum validity period falls from 398 days to 47 days. SAN validation data reuse falls from 398 days to 10 days. Non-SAN validation data reuse falls from 825 days to 398 days. The reductions begin in March 2026 and conclude in March 2029.
The current Baseline Requirements revision table records SC081 as version 2.1.5, adopted 2025-04-11 and effective 2025-05-16, and its relevant-dates table sets the staged limits: a 200-day maximum subscriber certificate validity effective 2026-03-15, a 100-day maximum effective 2027-03-15, and corresponding domain-name and IP-address validation reuse limits of 200 days and 100 days on the same dates. The 47-day and 10-day figures are future-dated, not current. Anyone who reads the ballot as a description of today’s rules has misread the artifact.
The operative text lives in the Server Certificate Working Group repository, which maintains the Baseline Requirements, EV Guidelines, and Network Security Requirements as final guidelines in docs/BR.md, docs/EVG.md, and docs/NSR.md. The ballot page summarizes; the repository carries the redline. For an operator, the repository is the document that matters.
The revocation section is the argument
The security case for shorter lifetimes is familiar and does not need restating. What deserves close reading is the section the ballot labels Adjacent Solutions, and specifically its treatment of revocation. The proposer writes that relying solely on revocation is untenable, and gives three reasons. Scalability: certificate revocation services must handle a large volume of requests, and growth can overwhelm existing infrastructure, producing delays and failures. Reliability: status services require additional connections to third-party systems unassociated with the website, and the need for action by multiple parties means not every problematic certificate is revoked, let alone revoked on time. User impact: each connection may trigger a status query, and timeouts and retries increase page-load times or cause clients to abandon the query.
Then comes the sentence that carries the cost argument: “Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.”
Read that as a trade, because it is one. If revocation is unreliable at scale, there are at least two responses. One is to fund and harden revocation infrastructure. The other is to make certificates expire before the unreliability has time to matter. The ballot chooses the second, and says so. The reliability burden does not disappear; it moves. It moves from the relying party, which no longer needs a status answer to be correct, onto the subscriber, which now needs a renewal pipeline that works on a schedule measured in weeks rather than years. That is a defensible allocation. It is not a neutral one, and the ballot’s own text is the evidence for calling it an allocation rather than a discovery.
The 24-hour inference and what it concedes
One passage in the ballot is easy to skim past and hard to forget. The Baseline Requirements require CAs to revoke certificates within 24 hours under certain circumstances. The ballot reasons that it “can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period.” Then it concedes the gap: “While this requirement has been part of the TBRs since its first adopted version, the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation.”
This is the ballot admitting that a requirement has been on the books for years without the operational reality to match it. The shorter-lifetime schedule is, in part, an attempt to make practice catch up with a promise the requirements already made. That framing is more honest than the usual security narrative, and it is also more consequential: it means the schedule is not primarily about new threats. It is about closing a gap between what the rules assumed and what operators actually built.
Where the enforcement actually lives
The Baseline Requirements page states the condition plainly: the requirements “are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying-party Application Software Suppliers.” This is the hinge of the entire governance story, and it is routinely missed.
The Forum is not a regulator. It is a venue where a supermajority of issuers and a majority of consumers agree on a text. The text binds a CA when a root program adopts it. The 47-day number is a Forum output; the coercion is a browser root-program input. Analysts who treat the ballot as the operative rule confuse the venue with the enforcement mechanism. The four consumer votes are not four votes among many. They are the four organizations whose root programs convert the text into a condition of trust.
This is not a criticism of the arrangement. It is a description of where accountability sits. If a CA fails to meet the schedule, the consequence is not a Forum sanction. It is a root-program decision. The chain of responsibility runs through four consumer organizations, and no protocol document supplies it.
Protocols detect; they do not enforce
It helps to be precise about what the standards layer does and does not provide, because the ballot’s revocation argument is often read as a claim about protocol failure. It is not. RFC 5280 profiles X.509 certificates and CRLs and describes certification path validation, but it states that it “does not prescribe legally binding rules or duties.” RFC 6962 describes Certificate Transparency as a mechanism to mitigate misissuance through publicly auditable, append-only logs, and is equally clear about its limits: “The logs do not themselves prevent misissue, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance.”
So the standards layer gives us detection and signaling. It does not give us enforcement, and it does not give us a reliability guarantee for status services. The ballot’s argument is about scale, reliability, and user impact — operational properties, not protocol correctness. When the ballot says revocation is untenable, it means the operational system around revocation, not the ASN.1.
This distinction matters for how operators should read the schedule. Shorter lifetimes do not fix revocation. They reduce the window in which a revocation failure is consequential. That is a different claim, and a more modest one.
The half of the ballot nobody quotes
Lifetime reduction is visible. It shows up in expiry dates, in monitoring dashboards, in the calendar. The SAN reuse reduction is invisible until it fails. Moving domain-validation reuse from 398 days to 10 days means that, by the end of the schedule, almost every renewal will require a fresh proof of control. An organization with a mature ACME pipeline will barely notice. An organization whose validation step waits on a person to click an email or paste a DNS record will discover the change at the worst possible moment.
The ballot acknowledges this indirectly. It lists as an ancillary benefit “increased consistency of quality, stability, and availability of certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates,” and adds that increased deployment of robust, bi-directional automation “is not a panacea for challenges in the Web PKI, but it certainly helps.” That is the proposer’s own framing: automation is a benefit, not a precondition, and the ballot does not claim every operator is ready.
The operational risk therefore concentrates in a specific population — organizations with manual validation, legacy platforms, or certificate estates they cannot fully enumerate. That population is not the one that lobbied for the ballot, and it is not the one that will enforce it. It is the one that will absorb the cost.
What the vote arithmetic leaves unresolved
Return to the tally. Twenty-five issuer yeses, five issuer abstentions, four consumer yeses. The bylaws were satisfied. The schedule is adopted. The enforcement will come from root programs. None of that is in dispute.
What the artifacts do not answer is the question the ballot itself raises but does not resolve. If revocation is unreliable at scale, and if the chosen remedy is to shorten lifetimes so that unreliability matters less, then the cost of that unreliability has been re-priced onto subscribers’ renewal infrastructure. The ballot names the trade. It does not name who bears it, or whether the bearing is distributed fairly across the organizations that must now automate.
That is the question the record leaves open. The five issuer abstentions are the closest thing to a recorded signal that some issuers saw the cost differently. But abstention is not a rationale, and the tally does not tell us what the abstainers thought. What we have is a schedule, a vote, and a concession about practice lagging policy. The rest is inference, and it should be labeled as such.
FAQ
Did the ballot take 47 days to pass?
No. The 47-day figure is the eventual maximum certificate lifetime, not a voting period. The ballot page records a discussion period beginning January 28, 2025, and a voting period in April 2025, with adoption recorded on April 11, 2025.
Is the 47-day limit in force now?
No. The Baseline Requirements relevant-dates table sets a 200-day maximum effective 2026-03-15 and a 100-day maximum effective 2027-03-15. The 47-day and 10-day figures are future-dated, concluding in March 2029.
Are the Baseline Requirements legally binding on CAs?
Not by themselves. The Baseline Requirements page states they are not mandatory for CAs unless and until adopted and enforced by relying-party application software suppliers. The binding force comes through root programs.
Does the ballot say revocation is technically broken?
No. The ballot’s argument is about scalability, reliability, and user impact at the current scale of the internet. It does not claim the CRL or OCSP protocols fail as protocols.
Who proposed and endorsed the ballot?
The motion was proposed by Clint Wilson of Apple and endorsed by Nick France of Sectigo, Ryan Dickson of Google Chrome, and Ben Wilson of Mozilla. All four certificate consumers voted yes.
Primary sources
- CA/Browser Forum, Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods — voting results, motion text, revocation rationale, and schedule.
- CA/Browser Forum, Baseline Requirements, version 2.3.1 — revision table and relevant-dates table.
- CA/Browser Forum, servercert repository — maintained Baseline Requirements, EV Guidelines, and Network Security Requirements.
- IETF, RFC 5280 — X.509 and CRL profile; statement that it prescribes no legally binding rules or duties.
- IETF, RFC 6962 — Certificate Transparency; statement that logs detect rather than prevent misissuance.