Skip to main content

2.2. Multiple Certificate Status Request Record

Clients that support a certificate status protocol like OCSP may send the "status_request_v2" extension to the server in order to use the TLS handshake to transfer such data instead of downloading it through separate connections. When using this extension, the "extension_data" field (defined in Section 7.4.1.4 of [RFC5246]) of the extension SHALL contain a CertificateStatusRequestListV2 where:

  struct {
    CertificateStatusType status_type;
    uint16 request_length; /* Length of request field in bytes */
    select (status_type) {
      case ocsp: OCSPStatusRequest;
      case ocsp_multi: OCSPStatusRequest;
    } request;
  } CertificateStatusRequestItemV2;

  enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;

  struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions request_extensions;
  } OCSPStatusRequest;

  opaque ResponderID<1..2^16-1>;
  opaque Extensions<0..2^16-1>;

  struct {
    CertificateStatusRequestItemV2
                     certificate_status_req_list<1..2^16-1>;
  } CertificateStatusRequestListV2;

In the OCSPStatusRequest (originally defined by [RFC6066]), the "ResponderID" provides a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence has the special meaning that the responders are implicitly known to the server, e.g., by prior arrangement, or are identified by the certificates used by the server. "Extensions" is a DER encoding [X.690] of the OCSP request extensions, and if the server supports the forwarding of OCSP request extensions, this value MUST be forwarded without modification.

Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as defined in [RFC6960]. "Extensions" is imported from [RFC5280]. A zero-length "request_extensions" value means that there are no extensions (as opposed to a DER-encoded zero-length ASN.1 SEQUENCE, which is not valid for the "Extensions" type).

Servers that support a client's selection of responders using the ResponderID field could implement this selection by matching the responder ID values from the client's list with the ResponderIDs of known OCSP responders, either by using a binary compare of the values or a hash calculation and compare method.

In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is unclear about its encoding; for clarification, the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING (note that implementations based on an existing OCSP client will need to be checked for conformance to this requirement). This has been clarified in [RFC6960].

The items in the list of CertificateStatusRequestItemV2 entries are ordered according to the client's preference (favorite choice first).

A server that receives a client hello containing the "status_request_v2" extension MAY return a suitable certificate status response message to the client along with the server's certificate message. If OCSP is requested, it SHOULD use the information contained in the extension when selecting an OCSP responder and SHOULD include request_extensions in the OCSP request.

The server returns a certificate status response along with its certificate by sending a "CertificateStatus" message (originally defined by [RFC6066]) immediately after the "Certificate" message (Section 7.4.2 of [RFC5246]) (and before any "ServerKeyExchange" or "CertificateRequest" messages). If a server returns a "CertificateStatus" message in response to a "status_request_v2" request, then the server MUST have included an extension of type "status_request_v2" with empty "extension_data" in the extended server hello.

The "CertificateStatus" message is conveyed using the handshake message type "certificate_status" (defined in [RFC6066]) as follows (updated from the definition in [RFC6066]):

  struct {
    CertificateStatusType status_type;
    select (status_type) {
      case ocsp: OCSPResponse;
      case ocsp_multi: OCSPResponseList;
    } response;
  } CertificateStatus;

  opaque OCSPResponse<0..2^24-1>;

  struct {
    OCSPResponse ocsp_response_list<1..2^24-1>;
  } OCSPResponseList;

An "OCSPResponse" element (originally defined by [RFC6066]) contains a complete, DER-encoded OCSP response (using the ASN.1 [X.680] type OCSPResponse defined in [RFC6960]). Only one OCSP response, with a length of at least one byte, may be sent for status_type "ocsp".

An "ocsp_response_list" contains a list of "OCSPResponse" elements, as specified above, each containing the OCSP response for the matching corresponding certificate in the server's Certificate TLS handshake message. That is, the first entry is the OCSP response for the first certificate in the Certificate list, the second entry is the response for the second certificate, and so on. The 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. Individual elements of the list MAY have a length of 0 (zero) bytes if the server does not have the OCSP response for that particular certificate stored, in which case the client MUST act as if a response was not received for that particular certificate. If the client receives a "ocsp_response_list" that does not contain a response for one or more of the certificates in the completed certificate chain, the client SHOULD attempt to validate the certificate using an alternative retrieval method, such as downloading the relevant CRL; OCSP SHOULD in this situation only be used for the end-entity certificate, not intermediate CA certificates, for reasons stated above.

Note that a server MAY also choose not to send a "CertificateStatus" message, even if it has received a "status_request_v2" extension in the client hello message and has sent a "status_request_v2" extension in the server hello message. Additionally, note that a server MUST NOT send the "CertificateStatus" message unless it received either a "status_request" or "status_request_v2" extension in the client hello message and sent a corresponding "status_request" or "status_request_v2" extension in the server hello message.

Clients requesting an OCSP response and receiving one or more OCSP responses in a "CertificateStatus" message MUST check the OCSP response(s) and abort the handshake if the response is a "revoked" status or other unacceptable responses (as determined by client policy) with a bad_certificate_status_response(113) alert. This alert is always fatal.

If the OCSP response received from the server does not result in a definite "good" or "revoked" status, it is inconclusive. A TLS client in such a case MAY check the validity of the server certificate through other means, e.g., by directly querying the certificate issuer. If such processing still results in an inconclusive response, then the application using the TLS connection will have to decide whether to close the connection or not. Note that this problem cannot be decided by the generic TLS client code without information from the application. If the application doesn't provide any such information, then the client MUST abort the connection, since the server certificate has not been sufficiently validated.

An example of where the application might wish to continue is with EAP-TLS (Extensible Authentication Protocol - TLS), where the application can use another mechanism to check the status of a certificate once it obtains network access. In this case, the application could have the client continue with the handshake, but it MUST NOT disclose a username and password until it has fully validated the server certificate.

Last updated on