doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc6961.txt b/doc/rfc/rfc6961.txt
new file mode 100644
index 0000000..2dc4a6d
--- /dev/null
+++ b/doc/rfc/rfc6961.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      Y. Pettersen
+Request for Comments: 6961                                     June 2013
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                   The Transport Layer Security (TLS)
+             Multiple Certificate Status Request Extension
+
+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
+   about not only the server's 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.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6961.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pettersen                    Standards Track                    [Page 1]
+
+RFC 6961          Multiple Certificate Status Extension        June 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
+   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 prevent a
+   client from offering the server multiple status methods.
+
+
+
+Pettersen                    Standards Track                    [Page 2]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+   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 [RFC6960]
+   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 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
+
+
+
+
+Pettersen                    Standards Track                    [Page 3]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+   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].
+
+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
+   "status_request_v2" in the ExtensionType enum (originally defined by
+   [RFC6066]), which uses the following value:
+
+     enum {
+       status_request_v2(17), (65535)
+     } ExtensionType;
+
+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;
+
+
+
+
+
+Pettersen                    Standards Track                    [Page 4]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+     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
+
+
+
+Pettersen                    Standards Track                    [Page 5]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+   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
+
+
+
+Pettersen                    Standards Track                    [Page 6]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+   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.
+
+
+
+
+
+
+Pettersen                    Standards Track                    [Page 7]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+3.  IANA Considerations
+
+   Section 2.1 defines the new TLS extension status_request_v2 (17)
+   enum, which has 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 is
+   now maintained by IANA.  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 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 [RFC6960] for further details.
+
+   This extension allows 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 [RFC6960] apply to OCSP requests and
+   responses.
+
+
+
+
+Pettersen                    Standards Track                    [Page 8]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+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
+
+   [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.
+
+
+
+
+
+
+Pettersen                    Standards Track                    [Page 9]
+
+RFC 6961          Multiple Certificate Status Extension        June 2013
+
+
+Author's Address
+
+   Yngve N. Pettersen
+
+   EMail: yngve@spec-work.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pettersen                    Standards Track                   [Page 10]
+