In public key cryptography, a certificate may be revoked before it expires, which signals that it is no longer valid.
The Heartbleed vulnerability, which was disclosed in 2014, triggered a mass revocation of certificates, as their private keys may have been leaked.
[5] Chrome and Firefox perform push-based checks for a small set of domains deemed critical.
[6] Browsers show little agreement in corner cases around certificate validity, potentially confusing even experienced users.
A significant factor in this growth is Let's Encrypt providing free domain validated certificates.
The size of the potentially-revocable set of certificates places requirements on the scalability of the revocation mechanism.
[8] In 2022, RFC 9325 characterised certificate revocation as an important problem with "no complete and efficient solution".
RFC 9325 places a normative requirement on TLS implementations to have some means of distrusting certificates.
The associated frequent certificate issuance typically requires automation (e.g., the ACME protocol) and may stress other infrastructural elements (e.g., transparency logs).
[10] Short-lived certificates also present complications with TLS connection resumption, though not necessarily insuperably.
[11] Revocation may be initiated by a certificate holder (who, for example, may know that a private key has been compromised), who informs the CA.
[15] One proposal to solve this involves submitting 'postcertificates' to Certificate Transparency logs for each revocation, which would also allow revocation to be performed without action by a CA;[16] an alternative proposal, also based around Certificate Transparency, involves CRVs being sent to the CT logs by CAs.
[25] 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.
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.
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.
[29] CRLs have scalability issues, and rely on the client having enough network access to download them prior to checking a certificate's status.
[18] 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.
[9] RFC 7633 defines an extension that embeds a requirement into a certificate to be stapled to a valid OCSP response.
A single filter constructed from a list of revoked certificates produces false positives.
[23] 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.
[23] 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.
[23] 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.
Due to the efficiency of CRVs over CRLs and OCSP responses, CAs may be incentivised to deploy Let's Revoke.