< draft-ietf-tls-multiple-cert-status-extension-04.txt   draft-ietf-tls-multiple-cert-status-extension-05.txt >
Network Working Group Y. Pettersen Network Working Group Y. Pettersen
Internet-Draft February 6, 2013 Internet-Draft March 29, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: August 10, 2013 Expires: September 30, 2013
The TLS Multiple Certificate Status Request Extension The TLS Multiple Certificate Status Request Extension
draft-ietf-tls-multiple-cert-status-extension-04 draft-ietf-tls-multiple-cert-status-extension-05
Abstract Abstract
This document defines the Transport Layer Security (TLS) Certificate This document defines the Transport Layer Security (TLS) Certificate
Status Version 2 Extension to allow clients to specify and support Status Version 2 Extension to allow clients to specify and support
multiple certificate status methods. Also defined is a new method multiple certificate status methods. Also defined is a new method
based on the Online Certificate Status Protocol (OCSP) that servers based on the Online Certificate Status Protocol (OCSP) that servers
can use to provide status information not just about the server's own can use to provide status information not just about the server's own
certificate, but also the status of intermediate certificates in the certificate, but also the status of intermediate certificates in the
chain. chain.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 10, 2013. This Internet-Draft will expire on September 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
1. Introduction 1. Introduction
The Transport Layer Security (TLS) Extension [RFC6066] framework The Transport Layer Security (TLS) Extension [RFC6066] framework
defines, among other extensions, the Certificate Status Extension defines, among other extensions, the Certificate Status Extension
that clients can use to request the server's copy of the current (also referred to as "OCSP stapling") that clients can use to request
status of its certificate. The benefits of this extension include a the server's copy of the current status of its certificate. The
reduced number of roundtrips and network delays for the client to benefits of this extension include a reduced number of roundtrips and
verify the status of the server's certificate and a reduced load on network delays for the client to verify the status of the server's
the certificate issuer's status response servers, thus solving a certificate and a reduced load on the certificate issuer's status
problem that can become significant when the issued certificate is response servers, thus solving a problem that can become significant
presented by a frequently visited server. when the issued certificate is presented by a frequently visited
server.
There are two problems with the existing Certificate Status There are two problems with the existing Certificate Status
extension. First, it does not provide functionality to request the extension. First, it does not provide functionality to request the
status information about intermediate Certification Authority (CA) status information about intermediate Certification Authority (CA)
certificates, which means the client has to request status certificates, which means the client has to request status
information through other methods, such as Certificate Revocation information through other methods, such as Certificate Revocation
Lists (CRLs), thus adding additional delay. Second, the current Lists (CRLs), introducing further delays. Second, the current format
format of the extension and requirements in the TLS protocol prevents of the extension and requirements in the TLS protocol prevents a
a client from offering the server multiple status methods. client from offering the server multiple status methods.
Many CAs are now issuing intermediate CA certificates that not only Many CAs are now issuing intermediate CA certificates that not only
specify the publication point for their CRLs in a CRL Distribution specify the publication point for their CRLs in a CRL Distribution
Point [RFC5280], but also specify a URL for their OCSP [RFC2560] Point [RFC5280], but also specify a URL for their OCSP [RFC2560]
server in Authority Information Access [RFC5280]. Given that client- server in Authority Information Access [RFC5280]. Given that client-
cached CRLs are frequently out of date, clients would benefit from cached CRLs are frequently out of date, clients would benefit from
using OCSP to access up-to-date status information about intermediate using OCSP to access up-to-date status information about intermediate
CA certificates. The benefit to the issuing CA is less clear, as CA certificates. The benefit to the issuing CA is less clear, as
providing the bandwidth for the OCSP responder can be costly, providing the bandwidth for the OCSP responder can be costly,
especially for CAs with many high-traffic subscriber sites, and this especially for CAs with many high-traffic subscriber sites, and this
skipping to change at page 3, line 36 skipping to change at page 3, line 48
methods, which would cause problems for interoperability between methods, which would cause problems for interoperability between
newer clients and older servers. This will not just be an issue for newer clients and older servers. This will not just be an issue for
the multiple status request mode proposed above, but also for any the multiple status request mode proposed above, but also for any
other future status methods that might be introduced. This will be other future status methods that might be introduced. This will be
true not just for the current PKIX infrastructure [RFC5280], but also true not just for the current PKIX infrastructure [RFC5280], but also
for alternative PKI structures. for alternative PKI structures.
The solution to this problem is to define a new extension, The solution to this problem is to define a new extension,
status_request_v2, with an extended format that allows the client to status_request_v2, with an extended format that allows the client to
indicate support for multiple status request methods. This is indicate support for multiple status request methods. This is
implemented using a list of CertificateStatusRequestItem records in implemented using a list of CertificateStatusRequestItemV2 records in
the extension record. As the server will select the single status the extension record. As the server will select the single status
method based on the selected cipher suite and the certificate method based on the selected cipher suite and the certificate
presented, no significant changes are needed in the server's presented, no significant changes are needed in the server's
extension format. extension format.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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. Multiple Certificate Status Extension
2.1. New extension 2.1. New extension
The extension defined by this document is indicated by the The extension defined by this document is indicated by the
"status_request_v2" in the ExtensionType enum, which uses the "status_request_v2" in the ExtensionType enum (originally defined by
following value: [RFC6066]), which uses the following value:
enum { enum {
status_request_v2(XX), (65535) status_request_v2(XX), (65535)
} ExtensionType; } ExtensionType;
[[ EDITOR: The value used for status_request_v2 has been left as [[ EDITOR: The value used for status_request_v2 has been left as
"XX". This value will be assigned when this draft progresses to "XX". This value will be assigned when this draft progresses to
RFC.]] RFC.]]
2.2. Multiple Certificate Status Request record 2.2. Multiple Certificate Status Request record
Clients that support a certificate status protocol like OCSP may send 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 the status_request_v2 extension to the server in order to use the TLS
handshake to transfer such data instead of downloading it through handshake to transfer such data instead of downloading it through
separate connections. When using this extension, the separate connections. When using this extension, the
"extension_data" field of the extension SHALL contain a "extension_data" field (defined by Section 7.4.1.4 in[RFC5246]) of
CertificateStatusRequestList where: the extension SHALL contain a CertificateStatusRequestList 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;
} CertificateStatusRequestItem;
enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType; 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;
struct { enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;
ResponderID responder_id_list<0..2^16-1>; struct {
Extensions request_extensions; ResponderID responder_id_list<0..2^16-1>;
} OCSPStatusRequest; Extensions request_extensions;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>; opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>; opaque Extensions<0..2^16-1>;
struct { struct {
CertificateStatusRequestItem certificate_status_req_list<1..2^16-1>; CertificateStatusRequestItemV2 certificate_status_req_list<1..2^16-1>;
} CertificateStatusRequestList; } CertificateStatusRequestList;
In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP In the OCSPStatusRequest (originally defined by [RFC6066]), the
responders that the client trusts. A zero-length "responder_id_list" "ResponderIDs" provides a list of OCSP responders that the client
sequence has the special meaning that the responders are implicitly trusts. A zero-length "responder_id_list" sequence has the special
known to the server, e.g., by prior arrangement, or are identfied by meaning that the responders are implicitly known to the server, e.g.,
the certificates used by the server. "Extensions" is a DER encoding by prior arrangement, or are identfied by the certificates used by
[CCITT.X690.2002] of the OCSP request extensions. the server. "Extensions" is a DER encoding [CCITT.X690.2002] of the
OCSP request extensions.
Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A
zero-length "request_extensions" value means that there are no zero-length "request_extensions" value means that there are no
extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not
valid for the "Extensions" type). valid for the "Extensions" type).
In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is
unclear about its encoding; for clarification, the nonce MUST be a unclear about its encoding; for clarification, the nonce MUST be a
DER-encoded OCTET STRING, which is encapsulated as another OCTET DER-encoded OCTET STRING, which is encapsulated as another OCTET
STRING (note that implementations based on an existing OCSP client STRING (note that implementations based on an existing OCSP client
will need to be checked for conformance to this requirement). will need to be checked for conformance to this requirement).
The list of CertificateStatusRequestItem entries MUST be in order of The items in the list of CertificateStatusRequestItemV2 entries are
preference. in order of the client's preference (favorite choice first).
A server that receive a client hello containing the A server that receives a client hello containing the
"status_request_v2" extension MAY return a suitable certificate "status_request_v2" extension MAY return a suitable certificate
status response message to the client along with the server's status response message to the client along with the server's
certificate message. If OCSP is requested, it SHOULD use the certificate message. If OCSP is requested, it SHOULD use the
information contained in the extension when selecting an OCSP information contained in the extension when selecting an OCSP
responder and SHOULD include request_extensions in the OCSP request. responder and SHOULD include request_extensions in the OCSP request.
The server returns a certificate status response along with its The server returns a certificate status response along with its
certificate by sending a "CertificateStatus" message immediately certificate by sending a "CertificateStatus" message (originally
after the "Certificate" message (and before any "ServerKeyExchange" defined by [RFC6066]) immediately after the [RFC5246] (Section 7.4.2)
or "CertificateRequest" messages). If a server returns a "Certificate" message (and before any "ServerKeyExchange" or
"CertificateRequest" messages). If a server returns a
"CertificateStatus" message in response to a status_request_v2 "CertificateStatus" message in response to a status_request_v2
request, then the server MUST have included an extension of type request, then the server MUST have included an extension of type
"status_request_v2" with empty "extension_data" in the extended "status_request_v2" with empty "extension_data" in the extended
server hello. The "CertificateStatus" message is conveyed using the server hello. The "CertificateStatus" message is conveyed using the
handshake message type "certificate_status" as follows (see also handshake message type "certificate_status" as follows (see also
[RFC6066]): [RFC6066]):
struct { struct {
CertificateStatusType status_type; CertificateStatusType status_type;
select (status_type) { select (status_type) {
skipping to change at page 6, line 19 skipping to change at page 6, line 26
case ocsp_multi: OCSPResponseList; case ocsp_multi: OCSPResponseList;
} response; } response;
} CertificateStatus; } CertificateStatus;
opaque OCSPResponse<0..2^24-1>; opaque OCSPResponse<0..2^24-1>;
struct { struct {
OCSPResponse ocsp_response_list<1..2^24-1>; OCSPResponse ocsp_response_list<1..2^24-1>;
} OCSPResponseList; } OCSPResponseList;
An "OCSPResponse" element contains a complete, DER-encoded OCSP An "OCSPResponse" element (originally defined by [RFC6066]) contains
response (using the ASN.1 [CCITT.X680.2002] type OCSPResponse defined a complete, DER-encoded OCSP response (using the ASN.1
in [RFC2560]). Only one OCSP response, with a length of at least one [CCITT.X680.2002] type OCSPResponse defined in [RFC2560]). Only one
byte, may be sent for status_type "ocsp". 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, An "ocsp_response_list" contains a list of "OCSPResponse" elements,
as specified above, each containing the OCSP response for the as specified above, each containing the OCSP response for the
matching corresponding certificate in the server's Certificate TLS matching corresponding certificate in the server's Certificate TLS
handshake message. That is, the first entry is the OCSP response for handshake message. That is, the first entry is the OCSP response for
the first certificate in the Certificate list, the second entry is the first certificate in the Certificate list, the second entry is
the response for the second certificate, and so on. The list MAY the response for the second certificate, and so on. The list MAY
contain fewer OCSP responses than there were certificates in the contain fewer OCSP responses than there were certificates in the
Certificate handshake message, but there MUST NOT be more responses Certificate handshake message, but there MUST NOT be more responses
than there were certificates in the list. Individual elements of the than there were certificates in the list. Individual elements of the
skipping to change at page 8, line 29 skipping to change at page 9, line 8
5. Acknowledgements 5. Acknowledgements
This document is based on [RFC6066] authored by Donald Eastlake 3rd. This document is based on [RFC6066] authored by Donald Eastlake 3rd.
6. Normative References 6. Normative References
[CCITT.X680.2002] [CCITT.X680.2002]
International International Telephone and Telegraph International International Telephone and Telegraph
Consultative Committee, "Abstract Syntax Notation One Consultative Committee, "Abstract Syntax Notation One
(ASN.1): Specification of basic notation", (ASN.1): Specification of basic notation", CCITT
CCITT Recommendation X.680, July 2002. Recommendation X.680, July 2002.
[CCITT.X690.2002] [CCITT.X690.2002]
International International Telephone and Telegraph International International Telephone and Telegraph
Consultative Committee, "ASN.1 encoding rules: Consultative Committee, "ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002. (DER)", CCITT Recommendation X.690, July 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 23 change blocks. 
60 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/