Revocation Check

CRLite is a Mozilla-developed technology that compresses and aggregates all known TLS certificate revocations into a single, highly efficient Bloom filter data structure. This allows browsers and verifiers to perform near-instantaneous revocation checks locally without querying a remote OCSP responder or downloading massive CRLs. It represents a privacy-preserving, scalable evolution of traditional revocation infrastructure.

A performance optimization where the web server periodically queries the OCSP responder and caches a signed, timestamped response. During the TLS handshake, the server 'staples' this response to the certificate, eliminating the need for the client to perform a separate OCSP lookup. This reduces latency and improves privacy by preventing the CA from seeing every client's browsing activity. The stapled response must be within its validity window, typically 24 hours.

A periodically published, signed list of serial numbers for certificates that have been revoked before their expiration date. Clients must download and parse the entire CRL to check a single certificate's status. CRLs are distributed via HTTP or LDAP and include a nextUpdate field indicating when a fresh list will be available. The primary drawback is size and staleness — large CRLs can be megabytes, and a revoked certificate remains valid until the next CRL publication cycle.

The ITU-T standard defining the format for public key certificates, forming the trust anchor for content credential signing. Each certificate binds a public key to a distinguished name and includes:

• Serial number: unique identifier checked during revocation
• Validity period: notBefore and notAfter dates
• Issuer signature: cryptographically chains to a trusted root CA
• CRL Distribution Points and OCSP responder URL: extensions directing clients where to check revocation status

A cryptographically signed, curated list of trusted Certificate Authorities, OCSP responders, and timestamp authorities that a validator application consults when verifying content credentials. The trust list acts as a policy enforcement point, allowing organizations to define which CAs are authoritative for their ecosystem. A certificate is considered valid only if it chains to a root CA present on the trust list and its revocation status is confirmed by an approved responder.

The complete cryptographic validation pipeline that includes revocation checking as a critical step. The validator engine performs:

1. Signature validation: verify the claim signature against the signer's public key
2. Certificate path construction: build the chain from end-entity to a trusted root
3. Revocation status check: query OCSP or CRL to ensure no certificate in the chain has been revoked
4. Trust list membership: confirm the root CA is on the approved trust list Failure at any step invalidates the entire content credential.

A trusted third-party service that issues signed timestamp tokens proving data existed before a specific moment. In revocation checking, timestamps are crucial for long-term validation: a signature verified with a timestamp taken before a certificate's revocation date remains valid even after revocation. The TSA's own certificate must also pass revocation checks, creating a nested trust dependency. The standard protocol is RFC 3161.