CRLs and OCSP

As previously mentionned, a certificate can be revoked or suspended. This information is usually provided in the form of a Certificate Revocation List (CRL), or through the Online Certificate Status Protocol (OCSP).

A CRL is a list of revoked (and/or suspended) certificates that is digitally signed and published by a CRL issuer. This issuer can be the CA having issued the certificates listed in the CRL, or it can be another CA in which case the CRL is called an “indirect CRL”. RFC 5280 ([R22]) provides a profile for X.509 CRLs.

The OCSP is a protocol defined in RFC 6960 ([R23]) that enables the determination of the (revocation) status of a certificate without the use of a CRL. An OCSP request, containing (among other things) information on the certificate for which the (revocation) status is requested, is sent to a server and a response, containing information of that (revocation) status, is provided by an OCSP responder. OCSP responses are signed by the OCSP responder, and the OCSP responder can be the CA having issued the certificate or another CA in which case the OCSP responder is called a “delegated OCSP responder”.

RFC 5280 section 6.3 describes an algorithm for the validation of CRLs, while Common PKI v2.0 part 5 section 2.3 ([R24]) describes an algorithm for checking the revocation status of a certificate using CRLs and OCSP responses.

Certificate Authority

Certification Authorities are entities issuing certificates and guaranteeing the correctness of their content. They manage the whole lifecycle of the certificates they issue, including the revocation services. Throughout this document, they will be denominated as:

• Issuing CA for the CAs that issue end-entity certificates:

• Intermediate CA for CAs that issue certificates to other CAs and are not root CAs;

• Root CA for the CAs that have at least one self-signed certificate.

TrustAnchors and TrustStores

Without going into the details and inner workings of the hierarchical trust model (this document does not intend to discuss the soundness of this model, the soundness of transitivity of trust, etc.), when a user is looking to validate a certificate, that is the user’s need to decide whether they can trust the binding between the public key and the subject of that certificate, they will make use of so called “trust anchors”.

A trust anchor, in the context of certificate validation, is a CA that is trusted by the user in such a way that if there exists a valid chain of certificate from that CA to a certificate, the user trusts the correctness of the information contained in that certificate taking into consideration the (revocation) status of that certificate.

The wording “valid chain of certificate” used above is voluntarily informal, but it can be more formally defined as meaning that there exists a prospective certification path such that the output of the certification validation path algorithm (see Certificate Chain and Certification Path Validation) provided with, as inputs, that prospective certification path, the trust anchor information and possibly other inputs, is a success indication.

Trust anchor information can be, and is often, provided as a (potentially self-signed) public key certificate.

A trust store is, in turn, a list of trust anchor information that can be, and is often, a list of directly trusted public key certificates.