Online Certificate Status Protocol (OCSP) with Certificate Validation Extension

Introduction In some secure protocols (e.g., TLS , IPsec ), the X.509 v3 certificate is the most commonly used means to authenticate the peer's identity. The validity of a certificate can be checked by relying parties by using a locally stored trust anchor and the received certificate chain. Moreover, relying parties can also use Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) to check the status of that certificate. Today, a large number of network devices across different vendors (or different trust domains) need to connect securely. For example, the first use case is that a user equipment (UE) roams onto a visited network, secure connection needs to be established between the visited network and the UE's home network for authentication and other services; the second use case is that in the 5G service-based architecture (SBA), network functions (NFs) from various vendors can interact with each other through secure connection for confidentiality and integrity. This makes the certificate validation more complex, since it requires every device to configure a list of trusted CAs and transmit the certificate chain. Moreover, factors such as CA changes further complicate the process. In the post-quantum era, the public key and signature sizes of post-quantum algorithms are significantly large compared to that of classical algorithms, leading to excessively large post-quantum certificates. This, in turn, results in higher transmission costs for certificate chains, thereby affecting the speed of secure connection establishment. This document provides a mechanism that uses the extended OCSP to additionally check the validity of a certificate, without transmitting and verifying the entire certificate chain.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

OCSP Extensions The message formats for OCSP requests and responses are defined in . also defines the standard extensions for OCSP messages following X.509 v3 certificate extensions (see ). Thus, each such extension requires an OID, a criticality flag, and ASN.1 syntax as defined by the OID. This document defines two new OCSP extensions: Certificate Validation extension in the OCSP request message and Certificate Hash extension in the OCSP response message. The criticality flags for these two extensions are optional: per , support for all OCSP extensions is optional. If the OCSP responder does not understand the requested extension, it will provide the baseline validation of the certificate.

OCSP Request Extension An OCSP requestor MAY wish to use this extended OCSP to additionally check the validity of a certificate. To do so, it SHOULD use an extension with the OID id-pkix-ocsp-cert-valid and the extnValue CertificateValidation. This extension is included as one of the request's singleRequestExtensions; it carries the preferred hash algorithms that will be used by the OCSP responder to compute the requested certificate's hash. The syntax of AlgorithmIdentifier is defined in . The client MUST support each of the specified preferred hash algorithms, and the client MUST specify the algorithms in the order of preference, from the most preferred to the least preferred.

OCSP Response Extension An OCSP responder MAY maximize the potential for ensuring interoperability by selecting a supported hash algorithm using the following order of precedence, as long as the selected algorithm meets all security requirements of the OCSP responder, where the first selection mechanism has the highest precedence:

Select an algorithm specified as a preferred hash algorithm in the requestor's request.
Select a mandatory or recommended hash algorithm, which is SHA-256 specified in this document.

If the OCSP responder does understand the requested extension, it SHOULD use an extension with OID id-pkix-ocsp-cert-hash and the extnValue CertHash. This extension is included as one of the response's singleExtensions; it carries a certificate hash that is requested by the OCSP requestor.

The "hashAlgorithm" field indicates a supported hash algorithm selected by the OCSP responder.
The "certHash" field contains the hash value of the requested certificate, which is computed over the entire DER-encoded certificate including the signature. The hash algorithm used to compute the "certHash" value is specified in the "hashAlgorithm" field.

For an OCSP request with the id-pkix-ocsp-cert-valid extension, if the status of a requested certificate is unknown or revoked (non-issued), then the OCSP responder SHOULD include the id-pkix-ocsp-cert-hash extension in the singleExtensions field of the corresponding SingleResponse, and the value of the extension SHALL be NULL.

OCSP CertID Update Recall that defines a struct CertID to identify a certificate, and the "issuerKeyHash" field of this struct is often computed from the issuer's certificate. As said that in , the primary reason to use the hash of the CA's public key in addition to the hash of the CA's name to identify the issuer is that it is possible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). However, if the names of different CAs are unique, then only the hash of CA's name can identify the issuer. In this case, it should be better to set the "issuerKeyHash" field to be optional as shown below, so the CertID value can be constructed only from a single end-entity certificate. Therefore, when receiving only the end-entity certificate, the CertID value (where the "issuerKeyHash" field is NULL) can be constructed without transmission of the entire certificate chain. Furthermore, the constructed CertID can be used with the extended OCSP to query both the status and the hash of the received certificate, which will be used to check whether the certificate is invoked and valid, respectively.