The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
obsoleted by
- rfc-8446 — The Transport Layer Security (TLS) Protocol Version 1.3
Extracted elements (24)
By combining certificate status checks into one extension, the CA server load depends on the number of issued certificates rather than the number of visitors to subscriber sites, addressing cases where direct OCSP requests for a single high-traffic site caused significant network problems for the issuing CA.
The existing Certificate Status extension (RFC 6066) only permitted a single status method per extension record, and TLS only allows one record per extension type. This made it impossible for clients to indicate support for new status methods while remaining compatible with older servers, motivating the new status_request_v2 extension with a list-based format.
The original Certificate Status extension did not provide a way to request status for intermediate CA certificates, forcing clients to use CRLs or direct OCSP queries for those certs and adding extra round trips. The ocsp_multi method was designed to allow the server to staple status responses for the entire certificate chain in one go.
For the 'id-pkix-ocsp-nonce' OCSP extension, RFC 2560 was unclear about encoding. RFC 6961 clarifies (consistent with RFC 6960) that the nonce MUST be a DER-encoded OCTET STRING encapsulated as another OCTET STRING; existing implementations based on OCSP clients must be checked for conformance.
A server MUST NOT send the CertificateStatus message unless it received either a 'status_request' or 'status_request_v2' extension in the client hello and sent a corresponding extension in the server hello.
Clients receiving one or more OCSP responses in a CertificateStatus message MUST check the responses and abort the handshake with a fatal bad_certificate_status_response(113) alert if any response has a 'revoked' status or other unacceptable status per client policy.
If a server returns a CertificateStatus message in response to a status_request_v2 request, the server MUST have included an extension of type 'status_request_v2' with empty 'extension_data' in the extended server hello.
If an inconclusive OCSP response cannot be resolved through other means and the application provides no guidance, the client MUST abort the connection because the server certificate has not been sufficiently validated.
If an individual element of the OCSPResponseList has a length of 0 bytes (server lacks that OCSP response), the client MUST act as if a response was not received for that particular certificate.
If the client receives an ocsp_response_list without a response for one or more certificates in the chain, the client SHOULD attempt to validate the certificate using an alternative retrieval method such as downloading the relevant CRL; OCSP SHOULD only be used for the end-entity certificate in this situation.
If the server supports forwarding of OCSP request extensions, the Extensions value from the client's OCSPStatusRequest MUST be forwarded to the OCSP responder without modification.
The ocsp_response_list MAY contain fewer OCSP responses than there were certificates in the Certificate handshake message, but there MUST NOT be more responses than there were certificates in the list.
Using the status_request_v2 extension significantly reduces privacy concerns around clients informing the certificate issuer about which sites they are visiting, since the server retrieves and staples the OCSP response rather than the client querying the CA's OCSP server directly.
CertificateStatusType is an enum with values ocsp(1) and ocsp_multi(2). Both use the same OCSPStatusRequest structure in the client request, but differ in the server response format: ocsp returns a single OCSPResponse, while ocsp_multi returns an OCSPResponseList.
The items in CertificateStatusRequestListV2 are ordered according to the client's preference, with the client's favorite choice first. The server selects a single status method based on the chosen cipher suite and presented certificate.
The 'status_request_v2' extension (ExtensionType value 17) is defined to allow clients to indicate support for multiple certificate status methods in a single TLS handshake extension, replacing the single-method limitation of the original 'status_request' extension from RFC 6066.
IANA created the 'TLS Certificate Status Types' registry under the 'Transport Layer Security (TLS) Extensions' registry. Values are assigned via IETF Review. Initial entries: 0 (Reserved), 1 (ocsp, from RFC 6066/6961), 2 (ocsp_multi, from RFC 6961), 3–255 (Unassigned).
The ExtensionType value 17 (status_request_v2) has been added to the IANA 'Transport Layer Security (TLS) Extensions' registry 'ExtensionType Values' list.
An attacker's server using a compromised key could pretend not to support the status_request_v2 extension. A client that requires OCSP validation SHOULD either contact the OCSP server directly or abort the handshake when the extension is not acknowledged.
The status_request_v2 extension allows clients to send arbitrary data (ResponderID list, Extensions) to the server. Server implementers must handle such data carefully to avoid introducing security vulnerabilities.
Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may improve security against attacks that attempt to replay OCSP responses; see Section 4.4.1 of RFC 6960 for details.
CertificateStatusRequestItemV2 contains a CertificateStatusType (1 byte), a uint16 request_length, and a variable-length OCSPStatusRequest. Multiple items are collected into CertificateStatusRequestListV2 with a list length field of 1..2^16-1 bytes.
OCSPStatusRequest contains a variable-length ResponderID list (each entry 1..2^16-1 opaque bytes) and an Extensions field (0..2^16-1 opaque bytes). Both are DER-encoded ASN.1 types as defined in RFC 6960; a zero-length Extensions means no extensions are present.
The CertificateStatus message is extended: for status_type ocsp_multi, the response field is an OCSPResponseList containing ocsp_response_list<1..2^24-1>, where each OCSPResponse element is an opaque<0..2^24-1> DER-encoded OCSP response.