Skip to main content

The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
draft-ietf-tls-multiple-cert-status-extension-08

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6961.
Author Yngve N. Pettersen
Last updated 2016-12-13 (Latest revision 2013-04-11)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6961 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Sean Turner
IESG note ** No value found for 'doc.notedoc.note' **
Send notices to (None)
IANA IANA review state IANA - Review Needed
IANA action state RFC-Ed-Ack
draft-ietf-tls-multiple-cert-status-extension-08
Network Working Group                                       Y. Pettersen
Internet-Draft                                            April 12, 2013
Intended status: Standards Track
Expires: October 14, 2013

         The TLS Multiple Certificate Status Request Extension
            draft-ietf-tls-multiple-cert-status-extension-08

Abstract

   This document defines the Transport Layer Security (TLS) Certificate
   Status Version 2 Extension to allow clients to specify and support
   several certificate status methods.  (The use of the Certificate
   Status extension is commonly referred to as "OCSP stapling".)  Also
   defined is a new method based on the Online Certificate Status
   Protocol (OCSP) that servers can use to provide status information
   not just about the server's own certificate, but also the status of
   intermediate certificates in the chain.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 14, 2013.

Copyright Notice

   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, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Pettersen               Expires October 14, 2013                [Page 1]
Internet-Draft   Multiple Certificate Status Extension        April 2013

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and 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 [RFC6066] framework
   defines, among other extensions, the Certificate Status Extension
   (also referred to as "OCSP stapling") that clients can use to request
   the server's copy of the current status of its certificate.  The
   benefits of this extension include a reduced number of roundtrips and
   network delays for the client to verify the status of the server's
   certificate and a reduced load on the certificate issuer's status
   response servers, thus solving a problem that can become significant
   when the issued certificate is presented by a frequently visited
   server.

   There are two problems with the existing Certificate Status
   extension.  First, it does not provide functionality to request the
   status information about intermediate Certification Authority (CA)
   certificates, which means the client has to request status
   information through other methods, such as Certificate Revocation
   Lists (CRLs), introducing further delays.  Second, the current format
   of the extension and requirements in the TLS protocol prevents a
   client from offering the server multiple status methods.

   Many CAs are now issuing intermediate CA certificates that not only
   specify the publication point for their CRLs in a CRL Distribution
   Point [RFC5280], but also specify a URL for their OCSP
   [I-D.ietf-pkix-rfc2560bis] server in Authority Information Access
   [RFC5280].  Given that client-cached CRLs are frequently out of date,
   clients would benefit from using OCSP to access up-to-date status
   information about intermediate CA certificates.  The benefit to the
   issuing CA is less clear, as providing the bandwidth for the OCSP
   responder can be costly, especially for CAs with many high-traffic
   subscriber sites, and this cost is a concern for many CAs.  There are

Pettersen               Expires October 14, 2013                [Page 2]
Internet-Draft   Multiple Certificate Status Extension        April 2013

   cases where OCSP requests for a single high-traffic site caused
   significant network problems for the issuing CA.

   Clients will benefit from the TLS server providing certificate status
   information regardless of type, not just for the server certificate,
   but also for the intermediate CA certificates.  Combining the status
   checks into one extension will reduce the roundtrips needed to
   complete the handshake by the client to just those needed for
   negotiating the TLS connection.  Also, for the Certification
   Authorities, the load on their servers will depend on the number of
   certificates they have issued, not on the number of visitors to those
   sites.  Additionally, using this extension significantly reduces
   privacy concerns around the clients informing the Certificate Issuer
   about which sites they are visiting.

   For such a new system to be introduced seamlessly, clients need to be
   able to indicate support for the existing OCSP Certificate Status
   method, and a new multiple-OCSP mode.

   Unfortunately, the definition of the Certificate Status extension
   only allows a single Certificate Status extension to be defined in a
   single extension record in the handshake, and the TLS Protocol
   [RFC5246] only allows a single record in the extension list for any
   given extension.  This means that it is not possible for clients to
   indicate support for new methods while still supporting older
   methods, which would cause problems for interoperability between
   newer clients and older servers.  This will not just be an issue for
   the multiple status request mode proposed above, but also for any
   other future status methods that might be introduced.  This will be
   true not just for the current PKIX infrastructure [RFC5280], but also
   for alternative PKI structures.

   The solution to this problem is to define a new extension,
   status_request_v2, with an extended format that allows the client to
   indicate support for multiple status request methods.  This is
   implemented using a list of CertificateStatusRequestItemV2 records in
   the extension record.  As the server will select the single status
   method based on the selected cipher suite and the certificate
   presented, no significant changes are needed in the server's
   extension format.

1.1.  Requirements Language

   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].

Pettersen               Expires October 14, 2013                [Page 3]
Internet-Draft   Multiple Certificate Status Extension        April 2013

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 defined by this document is indicated by the
   "status_request_v2" in the ExtensionType enum (originally defined by
   [RFC6066]), which uses the following value:

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

   [[ EDITOR: The value used for status_request_v2 has been left as
   "XX".  This value will be assigned when this draft progresses to
   RFC.]]

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 by Section 7.4.1.4 in[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>;

Pettersen               Expires October 14, 2013                [Page 4]
Internet-Draft   Multiple Certificate Status Extension        April 2013

     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 identfied by the certificates used by
   the server.  "Extensions" is a DER encoding [CCITT.X690.2002] of the
   OCSP request extensions, and if the server supports 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 [I-D.ietf-pkix-rfc2560bis].  "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 supports clients' selection of responders using the
   ResponderID field could implement this selection by matching the
   responder ID valuesfrom 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 [I-D.ietf-pkix-rfc2560bis].

   The items in the list of CertificateStatusRequestItemV2 entries are
   in order of 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.

Pettersen               Expires October 14, 2013                [Page 5]
Internet-Draft   Multiple Certificate Status Extension        April 2013

   The server returns a certificate status response along with its
   certificate by sending a "CertificateStatus" message (originally
   defined by [RFC6066]) immediately after the [RFC5246] (Section 7.4.2)
   "Certificate" message (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
   [CCITT.X680.2002] type OCSPResponse defined in
   [I-D.ietf-pkix-rfc2560bis]).  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

Pettersen               Expires October 14, 2013                [Page 6]
Internet-Draft   Multiple Certificate Status Extension        April 2013

   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 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, 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.

3.  IANA Considerations

   Section 2.1 defines the new TLS Extension status_request_v2 enum,
   which should be added to the ExtensionType Values list in the IANA
   Transport Layer Security (TLS) Extensions registry.

Pettersen               Expires October 14, 2013                [Page 7]
Internet-Draft   Multiple Certificate Status Extension        April 2013

   Section 2.2 describes a TLS CertificateStatusType Registry to be
   maintained by the IANA.  The new registry is called TLS Certificate
   Status Types and should be defined 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 "ExtensionType" in
   Section 2.2.

   Value   Description   Reference
   1       ocsp          [This RFC]
   2       ocsp_multi    [This RFC]

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 continue to monitor 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.

   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 [I-D.ietf-pkix-rfc2560bis] for
   further details.

   This extension allow the client to send arbitrary data to the server.
   The server implementers need to handle such data carefully to avoid
   introducing security vulnerabilities.

   The security considerations of [I-D.ietf-pkix-rfc2560bis] apply to
   OCSP requests and responses.

5.  Acknowledgements

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

6.  References

Pettersen               Expires October 14, 2013                [Page 8]
Internet-Draft   Multiple Certificate Status Extension        April 2013

6.1.  Normative References

   [CCITT.X680.2002]
              International International Telephone and Telegraph
              Consultative Committee, "Abstract Syntax Notation One
              (ASN.1): Specification of basic notation", CCITT
              Recommendation X.680, July 2002.

   [CCITT.X690.2002]
              International International Telephone and Telegraph
              Consultative Committee, "ASN.1 encoding rules:
              Specification of basic encoding Rules (BER), Canonical
              encoding rules (CER) and Distinguished encoding rules
              (DER)", CCITT Recommendation X.690, July 2002.

   [I-D.ietf-pkix-rfc2560bis]
              Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              draft-ietf-pkix-rfc2560bis-17 (work in progress), April
              2013.

   [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.

6.2.  Informative References

   [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

Pettersen               Expires October 14, 2013                [Page 9]
Internet-Draft   Multiple Certificate Status Extension        April 2013

   Yngve N. Pettersen

   Email: yngve@spec-work.net

Pettersen               Expires October 14, 2013               [Page 10]