Revocation: CRL & OCSP

What if a private key leaks before the cert expires? Issuer needs to revoke.

Two mechanisms:

CRL (Certificate Revocation List, RFC 5280):

• CA periodically publishes a list of revoked serial numbers.
• Client downloads CRL (URL in cert's CRL Distribution Points extension).
• Checks leaf's serial isn't in the list.

CRL problems:

• HUGE files at scale (Symantec's CRL was megabytes).
• Stale: published weekly; revocations have lag.
• Browsers often skip CRL entirely (too expensive).

OCSP (Online Certificate Status Protocol):

• Client sends OCSP request {cert_serial, issuer_pubkey_hash} to OCSP responder URL.
• Responder replies signed: {good | revoked | unknown} + timestamp.
• Real-time-ish (cached briefly).

OCSP problems:

• Privacy: responder learns which sites you visit.
• Performance: extra round trip.
• "Soft fail": browsers pass the cert if OCSP responder is unreachable (DOS = bypass revocation).

OCSP Stapling (the modern fix):

• Server fetches its own OCSP response periodically.
• Server staples (sends) the response in TLS handshake.
• Client doesn't query OCSP itself.
• No privacy leak. No extra round trip. Server caches for hours.

Must-Staple (RFC 7633): cert extension declaring "any TLS handshake without a stapled OCSP must fail." Strong revocation guarantee.

CRLite: Mozilla compresses all CRLs + OCSP states into a Bloom-cascade filter shipped with browser. ~1MB. Solves CRL/OCSP problems at the cost of some staleness.

Short-lived certs: Let's Encrypt's strategy. 90-day certs make revocation less critical — just wait for expiry.