CRLite

CRLite is the revocation system Mozilla built for Firefox, based on a 2017 academic design. It compresses the revocation status of the certificates in Certificate Transparency logs from participating CAs into compact filters. Mozilla's servers collect the CRLs that CAs publish, combine them with CT data and push regular updates to Firefox, which then answers "is this certificate revoked?" locally. Because the filters are built against the complete set of known certificates, they give definite answers for covered certificates.

Why it matters

Classic revocation checking forces a trade-off: live OCSP queries leak browsing history and are usually soft-fail, while downloading full CRLs is too heavy for a browser. CRLite avoids both. No per-site query reaches the CA, there is no added handshake latency, and an attacker cannot suppress the check by blocking a responder. It depends on CAs publishing complete CRLs and disclosing them to root programs, a data source that Ballot SC-063, which made CRLs mandatory, guarantees. Chrome takes a different approach with CRLSets, which cover a curated subset of revocations.

Example

Suppose the private key for example.com leaks and the CA revokes the certificate. The serial number appears in the CA's next CRL, Mozilla's pipeline includes it in the next CRLite update, and Firefox users visiting example.com then see a revoked-certificate error (SEC_ERROR_REVOKED_CERTIFICATE). This works even if an attacker blocks all traffic to the CA.

Common misconceptions

• CRLite is just a downloaded CRL. It is a compressed dataset derived from many CAs' CRLs and far smaller than the lists it is built from.
• Bloom-filter-style data must produce false alarms. CRLite's filters are constructed against the full set of logged certificates, so covered certificates get exact answers.
• Chrome uses CRLite too. Chrome uses its own CRLSets; CRLite is Mozilla's mechanism.