Revocation means the invalidation of a certificate during its validity period. Re- vocation is done by the CA that certified the binding. The main mechanisms for revocation are Certificate Revocation Lists (CRL) [83] and the Online Certificate Status Protocol (OCSP) [104]. There are many reasons, why a revocation may be required, such as organizational changes, identity changes regarding the subject’s identity, or the private key was compromised. In the last case, revocation is espe- cially important, in order to prevent the malicious use of the key by an attacker. In order to trigger a revocation the compromise needs to be detected first. This is only possible with a certain delay. The time period between compromise and its detection is called gray period. During the gray period, the PKI is in an insecure state, in particular, when a CA’s key is compromised.
CRL
CRLs are defined in [83]. CRLs are released by CAs in regular intervals and specify certificates that are revoked and have not yet expired. Within CRLs, the revoked certificates are identified by the issuer’s name together with the certificate’s serial number. Furthermore, they also may contain information about the reason for a certificate revocation and a date from which on the certificate needs to be considered invalid. There exist different forms of CRLs, such as full, delta or indirect CRLs which we do not explain here. For more details on the different CRL types we refer the reader to [13, 83].
CRLs are an offline mechanism for revocation checking. Relying entities can download the CRLs in regular time intervals from the CAs’ servers and then use these CRLs to check the revocation status of certificates during path validation. From where to get the CRL relevant for a certain certificate is specified in the cRLDistributionPoints extension of the certificate.
OCSP
CRLs can get rather large and introduce delays into revocation until the next update of a CRL is published. Therefore, the Online Certificate Status Protocol [104] was defined. As the name says, it is an online mechanism to check the revocation status for a certificate. To provide the OCSP service, so called OCSP servers are operated, either by the CAs themselves or by an additional service provider. OCSP servers are special servers from which relying entities can request revocation status information of a certificate on demand. Within the request, the relying entity specifies the certificate using the issuer’s name and the certificate’s serial number. OCSP also allows to request the status of several certificates aggregated into one request.
The OCSP responder replies to a request with a signed response. Three different answers are possible:
• revoked, which states that the specified certificate has been revoked.
• unknown, which states that the OCSP server has no information about a cer- tificate and is unable to give any answer about the status of the certificate.
• good, which indicates that the certificate is not revoked.
The answer good does not necessarily mean that a certificate is valid. The certifi- cate might be expired or never have been issued. The actual behavior is left open to the implementation. OCSP servers that reply with revoked to requests for non- issued certificates must include the extended-revoke extension according to RFC 6960 [104].
Besides these possible status answers, an OCSP response may contain any infor- mation contained in CRLs, and includes the date showing when the response was generated.
OCSP is capable to provide up-to-date revocation information. However if OCSP responders base their answers on CRLs, this advantage is lost. To sign OCSP responses, OCSP servers normally use their own signing key and a certificate that was issued by the CA for which the OCSP server is operated. As for CRLs, the address of the OCSP server responsible for a certain certificate is specified in the authorityInfoAccess extension.
OCSP stapling OCSP stapling means that an OCSP response is not provided by the OCSP server to relying entities, but by the key owner himself. To do so, a key owner requests the status for his own certificate (or all certificates in the certification path of his certificate) from an OCSP server as described above. The responses are
then transferred to the relying entity by the key owner. As the responses are signed along with the date of their generation by the OCSP server, the relying entity can verify their authenticity and timeliness as in standard OCSP. This is especially rel- evant in scenarios where the key owner and the relying entity communicate directly and exchange the certification path during the communication as in TLS which will be detailed in Section 2.3.2. OCSP stapling has been specified as the certificate sta- tus request TLS extension [76] for a single certificate, and was extended to multiple certificates in [103].
Compared to the standard use of OCSP, OCSP stapling has the advantage that additional online communication with the OCSP server can be omitted. This saves overhead and also protects the relying entity’s privacy, as the OCSP server is not able to track the communication of the relying entity. An additional benefit can be seen in the fact that the key owner can reuse the OCSP response for a certain time interval, depending on the required freshness of the response to be accepted by a relying entity. Thus, an OCSP response does not have to be newly generated every time a relying entity is verifies the key owner’s certification path.