Post-Quantum OCSP and CRL Design

Quick answer: Post-quantum revocation checking arrives at an unusual moment: the industry was already moving away from live OCSP before PQC signature sizes became a design concern. Let’s Encrypt, the largest CA by certificate volume, ended its OCSP service in August 2025, and the CA/Browser Forum made OCSP optional for publicly trusted CAs back in 2023. Chrome does not perform live OCSP or CRL fetches at all, relying instead on its own curated CRLSets; Firefox is transitioning away from live OCSP toward CRLite. Against that backdrop, an ML-DSA-signed OCSP response growing from roughly 300 bytes to well over 3,000 bytes, or a CRL’s per-entry signature overhead multiplying similarly, matters less for the browser-facing Web PKI than it does for enterprise and private PKI, where OCSP and CRL infrastructure is still actively relied on and directly controlled. This guide covers what actually changes in revocation checking under PQC, and why short-lived certificates may matter more to your design than either OCSP or CRL optimization.

Revocation checking gets treated as a footnote in most PQC migration planning, an afterthought once certificates and TLS are sorted. That undersells it, especially for private and enterprise PKI where OCSP responders and CRL distribution points are infrastructure you actually operate and scale, not something outsourced to a public CA’s disappearing service.

Key Takeaways

• Live OCSP was already declining before PQC became a design factor: Let’s Encrypt ended its OCSP service in August 2025, and the CA/Browser Forum made OCSP optional for publicly trusted CAs in 2023.
• Major browsers largely do not perform live revocation checks the classical way: Chrome uses curated CRLSets rather than live OCSP or CRL fetches; Firefox is moving from OCSP toward CRLite.
• AD CS supports ML-DSA-signed OCSP responses natively, associating the Online Responder with an ML-DSA subordinate CA and an ML-DSA signing template.
• CRL size grows with ML-DSA’s larger per-signature overhead, but CRLs already scale with revocation volume, so the base-plus-delta CRL pattern that manages that growth today extends naturally to PQC.
• Short-lived certificates, seven days or less under current CA/Browser Forum Baseline Requirements, are exempt from CRL and OCSP requirements entirely, sidestepping the PQC revocation-size question rather than solving it.

The Revocation Landscape Before PQC Even Enters the Picture

Understanding what to actually do about post-quantum OCSP and CRL requires understanding where revocation checking already stood before PQC signature sizes became relevant. Let’s Encrypt, the world’s largest certificate authority by volume, ended its OCSP service in August 2025, citing privacy cost and infrastructure complexity from responders fielding billions of daily requests. The CA/Browser Forum made OCSP optional, not mandatory, for publicly trusted CAs back in 2023. Browser behavior compounds the shift: Chrome does not perform live OCSP checks or fetch CRLs directly for most certificates, instead relying on CRLSets, a Google-curated, compressed subset of high-priority revocations distributed through Chrome’s own update mechanism, alongside an experimental broader-coverage system called CRLite. Firefox uses CRLite for intermediate CA revocation checking and, for leaf certificates, is transitioning away from live OCSP checking as its default behavior.

None of this is PQC-driven; it reflects years of accumulated frustration with OCSP’s privacy leakage (each request reveals which site a user is visiting to the CA) and soft-fail behavior that made live checking unreliable as a security control in the first place. The practical implication for PQC planning: for public Web PKI specifically, the browser-facing OCSP and CRL infrastructure that PQC signature size would most directly stress is already being bypassed by the clients that matter most.

Where OCSP and CRL Size Still Matters: Private and Enterprise PKI

The browser-driven shift away from live revocation checking does not extend to private and enterprise PKI, where OCSP responders and CRL distribution points are infrastructure you directly operate, and internal applications, VPN concentrators, and 802.1X network access control frequently do perform live revocation checks the classical way. For these environments, PQC signature size is a real, direct operational concern, not a moot point.

OCSP Response Size Under ML-DSA

An OCSP response is itself a signed object, and that signature grows exactly the way any other ML-DSA signature does: an ML-DSA-65 signature runs 3,309 bytes versus roughly 64 bytes for an equivalent ECDSA response, an increase that matters far more for OCSP than for a one-time TLS handshake, since OCSP is queried repeatedly, per certificate, per validation. AD CS supports this natively: configuring an Online Responder with an ML-DSA signing template, associated with an ML-DSA subordinate CA, produces ML-DSA-signed OCSP responses, verifiable the same way any Online Responder deployment is, by inspecting the signing certificate to confirm the ML-DSA parameter set and key size are actually in use.

The operational question worth planning for explicitly: OCSP stapling, where a server caches and presents the OCSP response itself rather than the client contacting the responder directly, absorbs the size increase at the server rather than the client, and remains the recommended pattern for private PKI where responders are under your own control, exactly as it is for classical certificates today.

CRL Growth and the Base-Plus-Delta Pattern

A CRL is signed by the issuing CA, so its overall signature grows the same way any other CA-signed object does under ML-DSA, and the list of revoked certificate entries within it, while not each individually carrying a full signature, still scales with the number of revocations the CA has processed. This is not a new problem PQC introduces; CRLs already grow large with high revocation volume under classical algorithms, and the base-plus-delta CRL pattern already used to manage that, a base CRL containing the full revoked set published infrequently, with smaller delta CRLs containing only recent changes published more often, extends directly to PQC-signed CRLs without needing a new mechanism. The signature overhead on each published CRL grows; the underlying scaling strategy does not need to change.

The Real Alternative: Short-Lived Certificates

This is the most consequential piece for PQC-era revocation design, and it is not a PQC-specific technique at all. Current CA/Browser Forum Baseline Requirements define short-lived certificates as those valid for seven days or less, and explicitly exempt them from CRL and OCSP requirements entirely, since a certificate that expires within a week limits a compromised key’s usable window to less than the time most revocation mechanisms take to propagate anyway. If a certificate never needs active revocation checking because it is simply too short-lived to be worth compromising and using before it expires on its own, the entire PQC-signature-size-in-OCSP-and-CRL question becomes moot for that certificate. Short-lived certificates require automated issuance and renewal infrastructure to be operationally viable at scale, but where that automation already exists or is being built as part of a broader PQC migration, it is worth evaluating short-lived issuance specifically as a way to sidestep the revocation-size problem rather than engineering around it.

Migration Sequencing for Revocation Infrastructure

Sequence revocation infrastructure alongside, not after, certificate issuance migration. An Online Responder configured for ML-DSA needs to be associated with the specific ML-DSA subordinate CA it serves, following the same root-first logic covered in our FIPS 203, 204, and 205 standards guide: revocation infrastructure for a hierarchy tier has to be ready by the time that tier starts issuing, not retrofitted afterward. For environments running the parallel classical-and-PQC hierarchy covered in our parallel PKI migration guide, both hierarchies need their own working, tested revocation infrastructure for the full duration of the coexistence period, since a relying party validating a certificate from either hierarchy needs a functioning path to check its status.

What We’d Actually Recommend

For private and enterprise PKI, plan OCSP and CRL infrastructure sizing around ML-DSA’s real signature overhead now, and lean on OCSP stapling to keep that overhead server-side rather than client-side. Evaluate short-lived certificate issuance specifically for high-volume, automatable certificate types, since it removes the PQC revocation-size question entirely for those certificates rather than requiring infrastructure to scale around it. Confirm your Online Responder and CRL infrastructure is tested and ready for each hierarchy tier before that tier starts issuing broadly, and if you run a parallel classical-and-PQC hierarchy, budget working revocation infrastructure for both, not just the new one.

How Encryption Consulting Can Help

Knowing which of your systems still perform live OCSP or CRL checks the classical way, versus which have moved to stapling, short-lived certificates, or browser-native revocation mechanisms, is exactly the inventory CBOM Secure is built to surface, so revocation infrastructure investment goes where it is actually needed rather than everywhere by default.

Our PQC Advisory Services sequence OCSP and CRL readiness alongside your broader certificate issuance migration, including evaluating short-lived certificate issuance as an alternative to scaling revocation infrastructure for high-volume certificate types. CertSecure Manager automates the issuance and renewal cadence that short-lived certificates require to be operationally viable, and manages revocation configuration across both classical and PQC hierarchies from a single platform.

A Design Question That’s Partly Already Answered

Post-quantum OCSP and CRL design lands in the middle of an industry that had already started moving past live revocation checking for the public web, which means the real design work concentrates where it matters most: private and enterprise PKI, where you still directly operate and depend on this infrastructure. ML-DSA’s larger signatures are a real, planned-for cost there, manageable through stapling and the existing base-plus-delta CRL pattern. The more consequential decision is whether short-lived, automatically renewed certificates make the whole revocation-size question moot for a meaningful share of your certificate population, which for many high-volume, automatable certificate types, they genuinely can.

Frequently Asked Questions

Does PQC make OCSP responses significantly larger?

Yes. An ML-DSA-65 signature runs roughly 3,309 bytes versus about 64 bytes for a classical ECDSA signature, and since an OCSP response is itself a signed object, that overhead applies to every response, an effect that compounds under repeated per-certificate queries.

Do public browsers still rely on live OCSP checking?

Largely no. Chrome uses its own curated CRLSets rather than live OCSP or CRL fetches for most certificates, and Firefox is transitioning away from live OCSP toward CRLite. This shift predates and is unrelated to PQC.

Can short-lived certificates avoid the PQC revocation-size problem entirely?

Yes, for certificates that qualify. Current CA/Browser Forum Baseline Requirements exempt certificates valid for seven days or less from CRL and OCSP requirements entirely, since the exposure window from a compromised short-lived certificate is smaller than the time most revocation mechanisms take to propagate.

Does AD CS support ML-DSA-signed OCSP responses?

Yes. AD CS Online Responders can be configured with an ML-DSA signing template associated with an ML-DSA subordinate CA, producing ML-DSA-signed responses for post-quantum revocation checking.

Does CRL size growth under PQC require a new scaling strategy?

No. The base-plus-delta CRL pattern already used to manage CRL growth under classical algorithms extends directly to PQC-signed CRLs; the per-CRL signature overhead grows, but the underlying strategy for managing overall CRL size does not need to change.