<b>Why did CRLs — the technology OCSP was meant to replace — quietly make a comeback?</b>

<b>Why did CRLs — the technology OCSP was meant to replace — quietly make a comeback?</b>

The CRL (Certificate Revocation List, RFC 5280 §5) is the original revocation mechanism: a CA publishes a signed, downloadable list of revoked serial numbers. It was deemed obsolete because lists grew to megabytes and clients had to download the whole thing. OCSP promised a lightweight per-certificate query. Yet the modern browser revocation story is circling back to list-based designs.

The reason is that OCSP's per-query model failed on privacy and reliability (soft-fail, responder outages, and the responder learning every site you visit). Browsers responded by building proprietary, aggressively-compressed pushed lists: Chrome's CRLSet and Mozilla's CRLite. CRLite in particular is a research-grade comeback — it uses cascading Bloom filters to compress the entire WebPKI revocation state into a few hundred kilobytes, pushed to the browser, queryable offline, with zero per-handshake network traffic and zero information leak to the CA.

The structural insight: revocation is a set-membership problem, and a probabilistic filter that the client downloads periodically beats a real-time query that leaks data and can be blocked. CRLite tunes the filter so false positives (a valid certificate flagged revoked) are eliminated by design via the cascade, not merely made rare.

Evidence vs. speculation: CRLite is published research (Larisch et al., IEEE S&P 2017) shipping in Firefox; CRLSet behavior is documented by Chrome. The performance numbers are measured, not projected.

<b>Further reading:</b> Larisch et al., "CRLite" (2017); RFC 5280 §5; Mozilla CRLite blog.

<b>Bottom line:</b> Revocation came full circle — not to classic CRLs, but to compressed, pushed, offline-queryable filters that fix OCSP's privacy and availability failures while keeping the list model's freedom from per-handshake network dependence.