up:: Classical Cryptography MOC

Certificate Revocation (CRL and OCSP)

Certificate revocation is the machinery that lets a certificate authority cancel an X.509 certificate before its validity period ends, so a compromised or mis-issued certificate stops being trusted even though its notAfter date has not arrived. A certificate carries a fixed lifetime baked in at issuance, and without revocation a stolen private key would stay trusted until that date no matter what. Two mechanisms carry revocation status across the Internet: the Certificate Revocation List (CRL), a signed roster of cancelled serial numbers defined in RFC 5280, and the Online Certificate Status Protocol (OCSP), a request-and-response lookup for a single certificate defined in RFC 6960. Both rest on a CA signing the revocation message, which is where the quantum transition lands: post-quantum signatures are far larger than ECDSA ones, so every CRL and every OCSP response grows, and that pressure reinforces the industry’s move toward short-lived certificates that barely need revocation at all.

Source: IETF, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, §5, May 2008, RFC 5280; IETF, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP,” RFC 6960, June 2013, RFC 6960.

The short version:

1. Revocation cancels a certificate before it expires, for cases like a stolen private key, a mis-issued certificate, or a decommissioned service.
2. A CRL is a signed, timestamped list of revoked serial numbers that a CA publishes and clients download, defined by RFC 5280.
3. OCSP answers a live yes-or-no question about one certificate, so a client checks a single serial number instead of pulling the whole list, defined by RFC 6960.
4. OCSP stapling has the web server fetch and attach its own fresh OCSP response during the TLS handshake, which fixes OCSP’s privacy and latency problems. It is the RFC 6066 Certificate Status Request extension.
5. Short-lived certificates are the alternative to checking revocation at all: if a certificate lives only days, a compromise expires almost on its own.
6. Post-quantum signatures (ML-DSA, SLH-DSA) are much larger than ECDSA signatures, so CRLs and OCSP responses both grow, which strengthens the case for shorter lifetimes over heavier revocation infrastructure.

Think of a certificate as a security badge with an expiration date printed on it. Revocation is the process of putting a lost or stolen badge on a “do not admit” list before that date.

A CRL is the printed list of every cancelled badge number, handed to the guard in bulk and reprinted on a schedule. OCSP is the guard picking up a phone and asking the badge office about one specific badge in real time. Stapling is the visitor carrying a freshly stamped note from the badge office so the guard never has to make the call. And a short-lived badge is one that only works for a single day, so a lost badge stops mattering by tomorrow morning regardless.

Why do certificates need to be revoked?

A certificate needs to be revoked whenever the binding it asserts stops being trustworthy before its natural expiry. The certificate’s signature freezes an identity, a public key, and a validity window into one signed object, and once signed that object cannot be edited. Revocation is the only way to withdraw trust from it early. The situations that force revocation:

1. Private-key compromise. If the private key matching the certificate’s public key is stolen or exposed, an attacker can impersonate the identity. This is the most urgent revocation reason and the one revocation exists to handle.
2. Mis-issuance. A CA that issued a certificate to the wrong party, with wrong contents, or in violation of policy must be able to pull it back.
3. Change of affiliation or decommissioning. A service is retired, a domain changes hands, or an employee leaves, and the certificate that named them should stop working.
4. CA compromise or policy failure. In the worst case an entire intermediate or issuing CA is revoked, which cascades to everything it signed.

The clock matters here. A certificate’s validity period already limits exposure, because a compromised key stops being trusted when the certificate expires anyway. Revocation is what closes the gap between compromise and expiry, and the length of that gap is exactly what the shorter-lifetime trend is trying to shrink.

Source: IETF, RFC 5280, §5, RFC 5280.

How does a Certificate Revocation List (CRL) work?

A CRL is a signed, timestamped list of the serial numbers a CA has revoked, published to a public location so any verifier can download it and check whether a certificate appears on it. RFC 5280 profiles the version 2 CRL for Internet use, and its structure mirrors the certificate itself: a body, a signature algorithm, and the CA’s signature over the body. The mechanics run in a fixed shape:

1. The CA maintains the list. When a certificate is revoked, its serial number is added as an entry, optionally with a reason code and an invalidity date. The CA signs the whole list with its private key, exactly as it signs certificates.
2. The list is timestamped and scheduled. Each CRL carries a thisUpdate field marking when it was issued and a nextUpdate field marking when the next one is due, so a verifier knows how stale its copy is.
3. A verifier fetches and checks it. A client downloads the current CRL, verifies the CA’s signature over it, and scans for the certificate’s serial number. Present means revoked; absent means still trusted within the update window.

The identifying fields inside a CRL are worth knowing because they surface in tooling:

Field	What it holds
thisUpdate	When this CRL was issued
nextUpdate	When the next CRL is scheduled, bounding how old the client’s copy may be
Revoked certificates	The list of revoked serial numbers, each an entry
Reason code	Why the certificate was revoked (key compromise, superseded, cessation of operation, and so on), a per-entry extension
CRL number	A monotonically increasing counter identifying this CRL version

RFC 5280 also defines delta CRLs, which list only the entries revoked since a named base CRL, so a client can update incrementally rather than re-downloading a large full list. The weakness of the whole CRL model is size and freshness: a busy CA’s list grows with every revocation, and a client trusts its copy until nextUpdate, so there is a built-in window where a freshly revoked certificate still looks valid.

Source: IETF, RFC 5280, §5, RFC 5280.

How does OCSP work, and how is it different from a CRL?

OCSP answers a live status question about one certificate instead of shipping the entire revocation list, which is the core difference. Where a CRL is a bulk download the client scans locally, the Online Certificate Status Protocol has the client send a small query to an OCSP responder and get back a signed answer about a single certificate. RFC 6960 defines it, and it obsoletes the earlier RFC 2560. The exchange:

1. The client builds a request. It identifies the certificate by a hash of the issuer’s name and public key plus the certificate’s serial number, then sends that to the OCSP responder named in the certificate’s Authority Information Access extension.
2. The responder answers with a signed status. The response is one of three values, good, revoked, or unknown, along with thisUpdate and nextUpdate validity times, and it is signed so the client can trust it came from the responder.
3. The client acts on the answer. good means proceed, revoked means reject, unknown means the responder cannot vouch for that certificate.

The tradeoffs against a CRL:

Dimension	CRL	OCSP
Data moved	The full list of revoked serials	One certificate’s status
Freshness	Bounded by the CRL’s nextUpdate schedule	Can be near-real-time per query
Privacy	The CA learns nothing about which certificates a client checks	The responder sees every certificate a client asks about
Availability	The list can be cached and served anywhere	A slow or unreachable responder stalls the handshake

OCSP fixes the freshness and bandwidth problems of a bulk CRL, at the cost of a privacy leak (the responder sees the client’s browsing) and a hard dependency on a live responder during the TLS handshake. Those two costs are what OCSP stapling exists to remove.

Source: IETF, RFC 6960, RFC 6960.

What is OCSP stapling and why does it help?

OCSP stapling has the certificate’s own server fetch a fresh, signed OCSP response ahead of time and attach it to the TLS handshake, so the client gets revocation status without ever contacting the responder itself. It is standardized as the Certificate Status Request extension in RFC 6066 §8, and it inverts who pays the cost of the lookup. The flow:

1. The server queries the responder on a schedule. The web server, which already holds the certificate, periodically asks the OCSP responder for its own status and caches the signed response.
2. The server staples the response into the handshake. When a client connects and includes the Certificate Status Request extension in its ClientHello, the server sends the cached OCSP response alongside its certificate.
3. The client validates the stapled response. Because the response is signed by the CA’s responder and timestamped, the client trusts it exactly as if it had fetched it directly.

Stapling removes both of OCSP’s problems at once. The client never reveals which sites it visits to the responder, so the privacy leak closes, and the handshake stops depending on a live third-party lookup, so a slow responder cannot stall the connection. The server caches one response and serves it to every visitor, which also takes load off the CA’s responder infrastructure. The one limitation is that a plain stapled response is advisory unless the certificate also carries a “must-staple” instruction requiring the server to supply it, since otherwise an attacker who suppresses the staple degrades the client to whatever fallback it allows.

Source: IETF, “Transport Layer Security (TLS) Extensions: Extension Definitions,” RFC 6066, §8, January 2011, RFC 6066.

Why are short-lived certificates replacing heavy revocation?

Short-lived certificates sidestep revocation by making the certificate expire before a compromise can do much damage, so the whole apparatus of lists and lookups becomes far less load-bearing. If a certificate is valid for only a few days, then a stolen key is worthless within days no matter what, and the verifier’s job shrinks back to a plain expiry check. The logic:

1. Revocation has always been the weak joint. CRLs go stale between updates, OCSP leaks browsing and can be suppressed, and many clients historically failed open when a revocation check could not complete, meaning a revoked certificate often still worked in practice.
2. A short lifetime bounds exposure directly. The maximum time a compromised certificate stays dangerous is its remaining validity, so cutting the lifetime cuts the risk without depending on every client checking revocation correctly.
3. Automation makes it practical. Automated issuance and renewal (the ACME protocol and its ecosystem) let a server rotate certificates on a tight schedule without human effort, which is what makes days-long lifetimes operationally realistic.

Public TLS certificate lifetimes have already trended sharply downward over the past decade, from years to about a year, with the industry moving toward far shorter windows. The direction of travel is to lean on frequent, automated re-issuance rather than on catching a bad certificate mid-life. That trend was already underway for reliability reasons, and the quantum transition gives it a second, independent push.

Source: IETF, RFC 5280, §5 (revocation model and its freshness limits), RFC 5280.

How does post-quantum cryptography make CRLs and OCSP responses bigger?

Post-quantum signatures are much larger than the ECDSA signatures they replace, and both a CRL and an OCSP response are signed objects, so both grow when the signing algorithm moves to a post-quantum scheme. The migration of the web PKI to post-quantum algorithms means the CA signs its certificates, its CRLs, and its OCSP responses with ML-DSA or the conservative SLH-DSA rather than ECDSA. The size gap is stark. An ECDSA P-256 signature is 64 bytes and its public key 65 bytes uncompressed. An ML-DSA-65 signature is 3,309 bytes and its public key 1,952 bytes, per FIPS 204. SLH-DSA signatures are larger still, running into the tens of kilobytes.

That expansion hits revocation in two ways:

1. Every OCSP response carries a post-quantum signature. An OCSP response is signed by the responder, so each response balloons from an ECDSA-signed message to an ML-DSA-signed one, which multiplies stapling overhead and per-query bandwidth.
2. A CRL’s signature grows, and long CRLs compound the cost. The CA’s signature over the CRL grows to post-quantum size, and because a busy CA’s list is already large, a bigger signature on top of a bigger transport problem makes bulk-list distribution heavier.

The upshot ties the two trends together. Heavier revocation messages make the case for avoiding heavy revocation, so the same size pressure that complicates post-quantum PKI reinforces the move toward short-lived certificates. If a certificate expires in days, its revocation almost never has to be published, checked, or transported at all, which is the cleanest way to avoid carrying multi-kilobyte revocation signatures across the network. This is why the post-quantum PKI conversation and the short-lifetime conversation keep arriving at the same destination.

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, Table 2 (ML-DSA parameter sizes), August 2024, FIPS 204.

Common misconceptions

1. “A revoked certificate stops working instantly everywhere.” It does not. A CRL client trusts its copy until nextUpdate, and many clients cache or fail open, so there is a real window where a revoked certificate still validates. Short lifetimes exist precisely because that window is hard to close.
2. “OCSP is always more secure than a CRL.” OCSP is fresher, but it leaks to the responder which certificates a client checks and it stalls if the responder is slow. Stapling fixes both, and a plain unstapled OCSP check can be suppressed by a network attacker.
3. “OCSP stapling is defined in RFC 6960.” RFC 6960 defines OCSP itself. Stapling is the Certificate Status Request extension defined in RFC 6066, a separate TLS mechanism.
4. “Short-lived certificates are a workaround, so revocation is obsolete.” Revocation still matters, but a short lifetime bounds the damage from a compromise directly, which is why the industry treats short lifetimes as the primary control and revocation as the backstop.
5. “Post-quantum migration only touches the certificate and leaves revocation alone.” CRLs and OCSP responses are both CA-signed, so the same signature-size growth that enlarges certificates also enlarges every revocation message.

Questions people ask

What is the difference between a CRL and OCSP? A CRL is a bulk, signed list of every revoked serial number that a client downloads and scans locally. OCSP is a live query about one certificate that returns a signed good, revoked, or unknown. CRLs favor privacy and cacheability; OCSP favors freshness and small per-check size.

What is OCSP stapling? It is the certificate’s server fetching a fresh, signed OCSP response in advance and attaching it to the TLS handshake, so the client gets revocation status without contacting the responder. It removes OCSP’s privacy leak and its dependency on a live responder during the handshake, and it is defined in RFC 6066.

Why are certificate lifetimes getting shorter? Because a short lifetime bounds the damage from a compromise directly, without relying on every client checking revocation correctly. Automated issuance and renewal make frequent rotation practical, so the industry is leaning on fast expiry rather than on catching bad certificates mid-life.

Does post-quantum cryptography break revocation? No. CRLs and OCSP keep working. The change is size: post-quantum signatures are far larger than ECDSA ones, so CRLs and OCSP responses both grow, which makes the heavy-revocation path costlier and pushes harder toward short-lived certificates.

How much bigger is a post-quantum signature? An ECDSA P-256 signature is 64 bytes. An ML-DSA-65 signature is 3,309 bytes with a 1,952-byte public key, per FIPS 204, and SLH-DSA signatures are larger still. Every signed revocation message inherits that growth.

Is a delta CRL different from a full CRL? Yes. A delta CRL lists only the certificates revoked since a named base CRL, so a client can update incrementally instead of re-downloading the entire list. RFC 5280 defines both.

---

Everything here is the map, given freely. When your team needs its own certificate and revocation infrastructure found, sized, and sequenced onto a post-quantum path, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.