Considerations Failure model If revocation status is unavailable (which may be benign or due to an attack), a client is faced with a dilemma when evaluating a certificate: it may
fail-soft and assume that the certificate is still valid; or it may
fail-hard and assume that the certificate has been revoked. This is a trade-off between security and availability: failing-soft allows
downgrade attacks, while failing-hard allows
denial of service (from attacks) or causes unavailability. An attacker with the ability to present a compromised certificate likely also has the ability to prevent the client performing an online revocation status check; in this case, failing-soft effectively provides no protection at all. Browsers have chosen this arm of the dilemma and preferred availability over security. Failing-hard can introduce new denial-of-service attack vectors. For example, if clients expect OCSP stapling and fail-hard otherwise, a denial of service against OCSP responders is amplified to a denial of service against all services wishing to use those OCSP responses.
Resource usage There are two scenarios for the evaluation of resource usage: normal conditions, and mass revocation events. Revocation schemes should be efficient under normal conditions, and functional during mass revocation events. Retrieving revocation information incurs bandwidth and latency costs for clients. During the 2014
Heartbleed mass revocation event, where revocation rates rose from 1% to 11%,
Cloudflare estimated that the
bandwidth that
GlobalSign used to distribute CRLs could have cost 400,000
USD (equivalent to USD in ).
Timeliness If revocation status is not freshly retrieved for every check (e.g., due to caching or periodic retrievals), there is a delay between a certificate being revoked and all clients being guaranteed to be aware of the revocation. This presents a trade-off between latency, efficiency, and security: longer cache times or less-frequent updates use fewer resources and reduce latency but mean that a compromised certificate can be abused for longer.
Privacy Clients that perform pull-based checks can leak the user's browsing information to third parties, namely the distributor of revocation information.
Auditability It is desirable to avoid creating a
trusted third party in a PKI. If an actor within a scheme is
auditable, then clients (or agents acting on behalf of clients) can provably verify that an actor is behaving correctly.
Deployability A revocation status distribution that places heavy burdens on CAs may not succeed, especially if the CA is unable to derive countervailing benefits from implementation. Reducing the number of parties that must make changes to adopt it also eases deployability: potentially involved are CAs, clients, server administrators, and server software producers.
Forwards compatibility is a double-edged sword, in that old clients and servers will not be disrupted by a new scheme, but their users may not realise that they are missing the benefits of revocation.
Architectures There are three broad architectures for how clients access revocation status:
pull-based, where clients retrieve revocation status at validation time;
push-based, where clients retrieve revocation status ahead of validation and cache it; and
network-assisted, where revocation checking is tightly integrated with the TLS protocol and separate checks may not be needed. Pull-based checking typically has latency and availability issues. Clients performing pull-based checking will typically cache responses for a short period. A purely pull-based check combined with failing-soft does not add security. Push-based checking is less bandwidth efficient than pull-based checking, but gains availability and privacy. Different methods may be used on a certificate-by-certificate basis, allowing for fine-tuning the trade-off: both
Google Chrome and
Mozilla Firefox perform push-based checks on a small set of critical certificates.
Certificate revocation lists A certificate revocation list (CRL) enumerates revoked certificates. They are cryptographically authenticated by the issuing CA. CRLs have scalability issues, and rely on the client having enough network access to download them prior to checking a certificate's status. A CRL contains information about all of the certificates revoked by a CA, which means distributors and clients must incur transfer costs for information that is likely irrelevant. A 2015 study found that the median certificate had a CRL with size 51 kB, and the largest CRL was 76 MB.
OCSP The Online Certificate Status Protocol (OCSP) allows clients to interactively ask a server (an
OCSP responder) about a certificate's status, receiving a response that is cryptographically authenticated by the issuing CA. It was designed to address issues with CRLs. A typical OCSP response is less than 1 kB. OCSP suffers from scalability issues. It relies on the client having network access at the time of checking the certificate's revocation status; further, the OCSP responder must be accessible and produce usable responses, or else the check will fail and the client must choose between failing-soft and failing-hard. Many certificate authorities do not publish useful OCSP responses for
intermediate certificates. As requests to the responder are made in response to users' browsing, OCSP responders can learn about the users' browsing, which is a
privacy issue. It also introduces
latency to connections, as the responder must be queried before a new connection can be used. A 2018 study found that 1.7% of requests to responders were unavailable at the network level, and a further c. 2% produced unusable OCSP responses, with significant hetereogeneity across CAs and client vantage points.
OCSP stapling OCSP stapling is a TLS extension providing for OCSP responses being provided to the client, together with the certificate, at connection initiation. OCSP stapling can solve the operational challenges of OCSP, namely additional network requests causing latency and privacy degradation. However, it can be susceptible to
downgrade attacks by an on-path attacker. RFC 7633 defines an extension that embeds a requirement into a certificate to be stapled to a valid OCSP response. With this extension, stapling can be effective for the case where a certificate has been compromised after proper issuance; however, if a certificate can be misissued without the extension, stapling may not provide any security. Beyond clients and CAs enabling stapling and the must-staple extension, server administrators must also take action to support stapling by regularly retrieving responses and then providing them to clients during the handshake. In 2018, only Firefox supported must-staple, and neither of the two most-used Web servers (
Apache httpd and
Nginx) supported OCSP stapling at all.
CRLite CRLite uses highly compressed static representations of certificate statuses to clients using
approximate membership query filters, allowing for efficient production, distribution and querying. CRLite allows clients to fail-hard and, as all clients retrieve the same information, CRLite has no privacy concerns. CRLite is deployable, only requiring an aggregator to retrieve CRLs from CAs and then provide the filter cascade and updates to it, and for clients to use it; no action from CAs is needed, and nor is any needed from certificate holders. The aggregator does not need to be a
trusted third party: the filter cascade can be audited to prove that it accurately reflects the input CRLs.
Private CAs also require special handling within CRLite; data from Firefox suggests that 5% of certificates are not in CT logs, either due to private CAs or merge delay. In the initial design, CRLite was a cascade of
Bloom filters. A single filter constructed from a list of revoked certificates produces
false positives. With an open domain, this is an insuperable problem for revocation checking. However, by using
Certificate Transparency to enumerate all unexpired certificates, an exhaustive list of false positives can be produced. This list is then used to construct a second filter, which is consulted if a certificate matches the first (and hence has a strictly smaller domain); if the second filter does not match, then it is a true positive and the certificate has been revoked; however, a match in the second filter may be a false negative, necessitating a third filter, and so on. As the universe is finite and the domain of each filter strictly decreases at each step, this procedure produces a finite filter cascade. The revocation status of all certificates in the Web PKI in January was estimated to be 10 MB in size when using the Bloom filter cascade, with updates of 580 kB per day. In March 2018, this had grown to 18 MB. In a simulation with 100 million certificates, a 1% daily expiration rate, and a 2% revocation rate, CRLite required an initial provision of 3.1 MB, and then 408 kB per day for updates. Mozilla, in a trial deployment of CRLite, found in 2024 that the amortised download rate was 26 MB over 10 days. CRLite was subsequently revised to use a more efficient, novel algorithm, dubbed
clubcards, which reduced data usage, as well as by observing that revocations are not uniformly distributed across CAs (i.e., some CAs have persistently higher revocation rates than others) nor across time (e.g., due to mass revocation events), and that, by partitioning certificates by these parameters, efficiency can be improved. The initial download of the clubcard membership test data in 2024 was 7.0 MB, covering 903 million valid and 8.7 million revoked certificates; updates, produced every six hours, were on average 95.5 kB, but could be compressed to 26.0 kB. With only issuer partitioning, this is within 12% of the theoretical lower bound; with more sophisticated partitioning using expiry/issuance dates as well, the amount left to exploit reaches up to 116%. After a trial deployment behind a
feature flag of the initial design of CRLite in Firefox version 68, Mozilla implemented the revised design in version 137 of Firefox, and in August 2025 it disabled OCSP for domain validated certificates in Firefox 142, effectively making the switch to production usage of CRLite. In a laboratory test, revocation checking was found to take as little as 10 μs per certificate, and, from field data, average TLS handshake times dropped from 172.4 ms to 143.4 ms, attributed to not needing to retrieve an OCSP response.
Let's Revoke Let's Revoke uses
bit vectors of revocation statuses (called
certificate revocation vectors, or CRVs) to allow large amounts of revocation statuses to be efficiently retrieved by clients. CAs generate CRVs for their own certificates, with one CRV per expiration date. CRV maintenance for CAs is
linear in the number of certificates issued. CAs must add a new field, a revocation number, to each issued certificate, allowing certificates from a single CA to be identified by a tuple of certificate expiration date and revocation number; this tuple allows a client to efficiently locate a bit giving the identified certificate's status within the CRV. CRVs may be compressed; they are expected to compress very well, as most bits will be unset most of the time. As each CRV is associated with a fixed expiration date, old CRVs can be efficiently discarded. Updates to CRVs are batched, with the update timestamped and signed for distribution to clients. The updates may be in one of three forms, with the optimal choice depending on the revocation rate, allowing for both efficient normal operation and mass revocation events. CRVs are expected to be small enough to enable push-based checking, but more constrained clients may still perform pull-based checks, only accessing select CRVs, or deferring retrieval of CRVs until certificate validation. A client using Let's Revoke with push-based checking is able to fail-hard for any certificate with a revocation number. The privacy impact and availability of Let's Revoke depends on the architecture: if all checks are push-based, then there is no privacy leakage and a reduced vulnerability to denial-of-service or downtime; if pull-based checks are used, however, some information about the user's activities is leaked (in the form of which CRVs are accessed), and the CRVs may be inaccessible at validation time. In a simulation with 100 million certificates, 1% daily expiration rate, and a 2% revocation rate, Let's Revoke required an initial provision of 2.2 MB, and then 114 kB per day for updates. Let's Revoke has not yet been widely deployed. Besides client implementations, it requires CAs to make operational changes, and does not provide as much information as CRLs or OCSP (only a bit per certificate for validity); CRLs or OCSP may still be used to supplement Let's Revoke and provide that additional information. Deployment can be performed CA by CA, with clients benefitting from fail-hard behaviour incrementally. Due to the efficiency of CRVs over CRLs and OCSP responses, CAs may be incentivised to deploy Let's Revoke.
Other proposals Private information retrieval techniques can allay the privacy concern with pull-based checks. Rather than clients performing revocation checks, a
middlebox could instead, centralising the cost of revocation checking and amortising it across many connections; the clients need to dedicate no storage to revocation information. Another proposal involved broadcasting revocation information on
FM radio. == References ==