RFC 6961

The Transport Layer Security (TLS) Multiple Certificate Status Request Extension

📅 published June 2013, from ietf

Okay bestie, here's the title block tea ☕🎀. This is RFC 6961, The Transport Layer Security (TLS) Multiple Certificate Status Request Extension, written by Y. Pettersen and dated June 2013. It's on the Standards Track 💅, with ISSN 2070-1721.

Abstract

okay so this doc defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension 🦋, which lets clients specify and support several certificate status methods at once. (The Certificate Status extension is commonly called "OCSP stapling" ✨, iykyk.) It also defines a new OCSP-based method that servers can use to share status info about not just their own certificate but also the status of intermediate certificates in the chain 🔥.

Status of This Memo

This is an Internet Standards Track document 💖.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741 🌸.

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6961 🧚.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 🎀.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 🌈.

1. Introduction ✨

The Transport Layer Security (TLS) Extension framework [RFC6066] defines, among other extensions, the Certificate Status extension (also called "OCSP stapling") 🦋. Clients can use it to ask the server for its copy of the current status of its certificate. The perks are a smaller number of roundtrips and network delays for the client to verify the server's certificate, plus a lighter load on the certificate issuer's status response servers. That's a big deal when the issued certificate is shown by a super popular server 🔥.

There are two problems with the existing Certificate Status extension 🙈. First, it can't request status info about intermediate Certification Authority (CA) certificates. That means the client has to get status info some other way, like Certificate Revocation Lists (CRLs), which adds more delays 💀. Second, the current extension format and the TLS protocol rules [RFC5246] stop a client from offering the server multiple status methods.

Lots of CAs are now issuing intermediate CA certificates that give the publication point for their CRLs in a CRL Distribution Point [RFC5280]. They also give a URL for their OCSP [RFC6960] server in Authority Information Access [RFC5280] 💅. Since client-cached CRLs are often out of date, clients would benefit from using OCSP to get up-to-date status info about intermediate CA certificates. The benefit for the issuing CA is less clear, though. Running the bandwidth for an OCSP responder can get expensive, especially for CAs with lots of high-traffic subscriber sites, and that cost worries a lot of CAs. There are cases where OCSP requests for one high-traffic site caused serious network problems for the issuing CA 😭.

Clients win big when the TLS server gives certificate status info regardless of type, not only for the server certificate but for the intermediate CA certificates too 👑. Combining the status checks into one extension cuts the roundtrips the client needs to finish the handshake down to just the ones needed to negotiate the TLS connection 🫶. For Certification Authorities, their server load depends on how many certificates they've issued, not on how many visitors those sites get. Using this extension also really cuts privacy concerns about clients telling the certificate issuer which sites they're visiting 🙈💜.

For a new system like this to roll out seamlessly, clients need to be able to indicate support for the existing OCSP Certificate Status method and a new multiple-OCSP mode 🎀.

Unfortunately, the Certificate Status extension definition only allows a single Certificate Status extension in a single extension record in the handshake. The TLS protocol [RFC5246] also only allows a single record in the extension list for any given extension 😤. So clients can't indicate support for new methods while still supporting older ones, which would cause interoperability problems between newer clients and older servers 💀. This won't just be a problem for the multiple status request mode proposed above. It will also affect any other future status methods that get introduced. It's true not just for the current PKIX infrastructure [RFC5280] but also for alternative PKI structures 🌸.

The fix is to define a new extension, "status_request_v2" 🦋, with an extended format that lets the client indicate support for multiple status request methods. It works using a list of CertificateStatusRequestItemV2 records in the extension record. Since the server picks the single status method based on the selected cipher suite and the certificate presented, no big changes are needed in the server's extension format 🧚✨.

1.1. Requirements Language

Okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖💅.

1.2. Presentation Language

This document defines protocol structures using the same conventions and presentation language as defined in Section 4 of [RFC5246] 🎀.

2. Multiple Certificate Status Extension 🌈

2.1. New Extension

The extension this document defines is indicated by "status_request_v2" in the ExtensionType enum (originally defined by [RFC6066]). It uses the following value 🧚:

  enum {
    status_request_v2(17), (65535)
  } ExtensionType;

2.2. Multiple Certificate Status Request Record ✨

Okay so, clients that speak a certificate status protocol like OCSP 🦋 can send the "status_request_v2" extension to the server 💖. That way the TLS handshake carries the status data, so nobody has to go downloading it over separate connections 🧚. When you use this extension, the "extension_data" field (defined in Section 7.4.1.4 of [RFC5246]) SHALL contain a CertificateStatusRequestListV2, and it's built like this:

  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;

Now, the OCSPStatusRequest (originally defined by [RFC6066]) is where the "ResponderID" comes in 🌸. It's a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence is special: it means the responders are implicitly known to the server, for example by prior arrangement, or because they're identified by the certificates the server uses 🔥. "Extensions" is a DER encoding [X.690] of the OCSP request extensions. If the server supports forwarding 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 there are no extensions. That's different from a DER-encoded zero-length ASN.1 SEQUENCE, which isn't valid for the "Extensions" type 🙈.

Servers that support a client's choice of responders through the ResponderID field can make that choice by matching the responder ID values in the client's list against the ResponderIDs of known OCSP responders. They can do the matching either with a binary compare of the values or with a hash calculation and compare method 🫶.

For the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is unclear about its encoding, so here's the clarification: the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING. Heads up, implementations based on an existing OCSP client will need to be checked for conformance to this requirement (note that!) ⚠️. This has been clarified in [RFC6960] ✨.

The items in the list of CertificateStatusRequestItemV2 entries are ordered by the client's preference, with the favorite choice first 👑.

A server that gets 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, the server SHOULD use the information contained in the extension when selecting an OCSP responder, and SHOULD include request_extensions in the OCSP request 🎀.

The server sends its certificate status response along with its certificate by sending a "CertificateStatus" message (originally defined by [RFC6066]) right after the "Certificate" message (Section 7.4.2 of [RFC5246]). It goes 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 uses the handshake message type "certificate_status" (defined in [RFC6066]). It's shaped like this (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]) holds a complete, DER-encoded OCSP response. It uses the ASN.1 [X.680] type OCSPResponse defined in [RFC6960] 🍓. For status_type "ocsp", only one OCSP response may be sent, and it has to be at least one byte long.

An "ocsp_response_list" is a list of "OCSPResponse" elements, as specified above. Each one holds the OCSP response for the matching certificate in the server's Certificate TLS handshake message. So the first entry is the OCSP response for the first certificate in the Certificate list, the second entry is 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 doesn't have the OCSP response for that particular certificate stored. In that case, the client MUST act as if a response was not received for that particular certificate 😭. If the client receives an "ocsp_response_list" that doesn't 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 🙃. Also, 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 that request an OCSP response and receive one or more OCSP responses in a "CertificateStatus" message MUST check the OCSP response(s). If the response is a "revoked" status, or any other unacceptable response (as determined by client policy), the client MUST abort the handshake with a bad_certificate_status_response(113) alert. This alert is always fatal 💀.

If the OCSP response from the server doesn't result in a definite "good" or "revoked" status, it's inconclusive 🤷‍♀️. A TLS client in that case MAY check the validity of the server certificate through other means, for example by directly querying the certificate issuer. If that processing still gives an inconclusive response, the application using the TLS connection has to decide whether to close the connection or not. This can't be decided by the generic TLS client code without information from the application. If the application doesn't provide any such information, the client MUST abort the connection, since the server certificate hasn't been sufficiently validated 😤.

An example of where the application might want to continue is EAP-TLS (Extensible Authentication Protocol - TLS). There, the application can use another mechanism to check the status of a certificate once it gets network access 🌟. In that 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 🔐.

3. IANA Considerations 🎀

Section 2.1 defines the new TLS extension status_request_v2 (17) enum. It's been added to the "ExtensionType Values" list in the IANA "Transport Layer Security (TLS) Extensions" registry 🦋.

Section 2.2 describes a TLS CertificateStatusType registry that IANA now maintains. The "TLS Certificate Status Types" registry has been created under the "Transport Layer Security (TLS) Extensions" registry. CertificateStatusType values are to be assigned via IETF Review as defined in [RFC5226]. The initial registry corresponds to the definition of "CertificateStatusType" in Section 2.2 💖.

Value   Description   Reference
-----------------------------------------
0       Reserved      [RFC6961]
1       ocsp          [RFC6066] [RFC6961]
2       ocsp_multi    [RFC6961]
3-255   Unassigned

4. Security Considerations 🔐

General security considerations for TLS extensions are covered in [RFC5246]. Security considerations for the particular extension specified in this document are given below. In general, implementers should keep up with the state of the art and address any weaknesses identified 👑.

4.1. Security Considerations for status_request_v2 💀

If a client requests an OCSP response, it must take into account that an attacker's server using a compromised key could (and probably would) pretend not to support the extension. In this case, a client that requires OCSP validation of certificates SHOULD either contact the OCSP server directly or abort the handshake 😱.

Using the OCSP nonce request extension (id-pkix-ocsp-nonce) may improve security against attacks that try to replay OCSP responses. See Section 4.4.1 of [RFC6960] for further details 🛡️.

This extension lets the client send arbitrary data to the server. Server implementers need to handle such data carefully to avoid introducing security vulnerabilities 🫣.

The security considerations of [RFC6960] apply to OCSP requests and responses 🧠.

5. Acknowledgements 🫶

This document is based on [RFC6066], authored by Donald Eastlake 3rd. 🌸

6. References 📚

6.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
  • [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
  • [X.680] ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", November 2008.
  • [X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008.

6.2. Informative References 📚

Okay bestie, last stop on the reference tour! 🦋 This one's the informative list, meaning the stuff that's good background reading but isn't required to implement the spec. The main one here is the OCSP spec.

  • [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. 🌸

Author's Address 💜

Yngve N. Pettersen 🎀

EMail: yngve@spec-work.net ✨

📦 where this page comes from