What actually makes short-lived certificates a substitute for revocation rather than a complement?

What actually makes short-lived certificates a substitute for revocation rather than a complement?

The reasoning is quantitative, and it explains why the CA/Browser Forum is steering the industry toward 47-day maximum lifetimes by 2029.

Revocation exists to answer one question: has this certificate's trust been withdrawn before its expiry? Every revocation system — CRLs (RFC 5280), OCSP (RFC 6960), CRLite — is a mechanism to propagate that "trust withdrawn" signal faster than the certificate would naturally expire. All of them are imperfect: CRLs are stale, OCSP soft-fails, and propagation lags.

Short-lived certificates attack the premise. If a certificate is valid for, say, 7 days, then the worst-case window between compromise and natural expiry is 7 days — comparable to, or better than, the real-world propagation delay of revocation infrastructure. The certificate revokes itself by expiring. This is only feasible because ACME (RFC 8555) made issuance fully automatic; you cannot renew a 90-day cert by hand every week.

The trade-off is explicit. Revocation handles the rare emergency precisely; short lifetimes handle it statistically. Below a certain validity period, maintaining OCSP for the residual window costs more than it buys — which is why Let's Encrypt began phasing out OCSP in 2025 in favor of CRLs plus short lifetimes.

Further reading: CA/Browser Forum ballot SC-081; Let's Encrypt's OCSP deprecation announcement (2024–2025).

Bottom line: short-lived certs make expiry itself the revocation channel — once lifetime approaches revocation's propagation delay, running OCSP for the gap stops paying for itself.