< draft-ietf-tls-multiple-cert-status-extension-06.txt   draft-ietf-tls-multiple-cert-status-extension-07.txt >
Network Working Group Y. Pettersen Network Working Group Y. Pettersen
Internet-Draft April 02, 2013 Internet-Draft April 11, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: October 04, 2013 Expires: October 13, 2013
The TLS Multiple Certificate Status Request Extension The TLS Multiple Certificate Status Request Extension
draft-ietf-tls-multiple-cert-status-extension-06 draft-ietf-tls-multiple-cert-status-extension-07
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 (commonly referred to as OCSP several certificate status methods. (The use of the Certificate
stapling). Also defined is a new method based on the Online Status extension is commonly referred to as "OCSP stapling".) Also
Certificate Status Protocol (OCSP) that servers can use to provide defined is a new method based on the Online Certificate Status
status information not just about the server's own certificate, but Protocol (OCSP) that servers can use to provide status information
also the status of intermediate certificates in the chain. not just about the server's own certificate, but also the status of
intermediate certificates in the 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 October 04, 2013. This Internet-Draft will expire on October 13, 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 3, line 26 skipping to change at page 3, line 15
for the issuing CA. for the issuing CA.
Clients will benefit from the TLS server providing certificate status Clients will benefit from the TLS server providing certificate status
information regardless of type, not just for the server certificate, information regardless of type, not just for the server certificate,
but also for the intermediate CA certificates. Combining the status but also for the intermediate CA certificates. Combining the status
checks into one extension will reduce the roundtrips needed to checks into one extension will reduce the roundtrips needed to
complete the handshake by the client to just those needed for complete the handshake by the client to just those needed for
negotiating the TLS connection. Also, for the Certification negotiating the TLS connection. Also, for the Certification
Authorities, the load on their servers will depend on the number of Authorities, the load on their servers will depend on the number of
certificates they have issued, not on the number of visitors to those certificates they have issued, not on the number of visitors to those
sites. 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 For such a new system to be introduced seamlessly, clients need to be
able to indicate support for the existing OCSP Certificate Status able to indicate support for the existing OCSP Certificate Status
method, and a new multiple-OCSP mode. method, and a new multiple-OCSP mode.
Unfortunately, the definition of the Certificate Status extension Unfortunately, the definition of the Certificate Status extension
only allows a single Certificate Status extension to be defined in a only allows a single Certificate Status extension to be defined in a
single extension record in the handshake, and the TLS Protocol single extension record in the handshake, and the TLS Protocol
[RFC5246] only allows a single record in the extension list for any [RFC5246] only allows a single record in the extension list for any
given extension. This means that it is not possible for clients to given extension. This means that it is not possible for clients to
skipping to change at page 4, line 39 skipping to change at page 4, line 33
"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 (defined by Section 7.4.1.4 in[RFC5246]) of "extension_data" field (defined by Section 7.4.1.4 in[RFC5246]) of
the extension SHALL contain a CertificateStatusRequestList where: the extension SHALL contain a CertificateStatusRequestListV2 where:
struct { struct {
CertificateStatusType status_type; CertificateStatusType status_type;
uint16 request_length; /* Length of request field in bytes */ uint16 request_length; /* Length of request field in bytes */
select (status_type) { select (status_type) {
case ocsp: OCSPStatusRequest; case ocsp: OCSPStatusRequest;
case ocsp_multi: OCSPStatusRequest; case ocsp_multi: OCSPStatusRequest;
} request; } request;
} CertificateStatusRequestItemV2; } CertificateStatusRequestItemV2;
skipping to change at page 5, line 4 skipping to change at page 4, line 45
struct { struct {
CertificateStatusType status_type; CertificateStatusType status_type;
uint16 request_length; /* Length of request field in bytes */ uint16 request_length; /* Length of request field in bytes */
select (status_type) { select (status_type) {
case ocsp: OCSPStatusRequest; case ocsp: OCSPStatusRequest;
case ocsp_multi: OCSPStatusRequest; case ocsp_multi: OCSPStatusRequest;
} request; } request;
} CertificateStatusRequestItemV2; } CertificateStatusRequestItemV2;
enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType; enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;
struct { struct {
ResponderID responder_id_list<0..2^16-1>; ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions; Extensions request_extensions;
} OCSPStatusRequest; } 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 {
CertificateStatusRequestItemV2 certificate_status_req_list<1..2^16-1>; CertificateStatusRequestItemV2 certificate_status_req_list<1..2^16-1>;
} CertificateStatusRequestList; } CertificateStatusRequestListV2;
In the OCSPStatusRequest (originally defined by [RFC6066]), the In the OCSPStatusRequest (originally defined by [RFC6066]), the
"ResponderIDs" provides a list of OCSP responders that the client "ResponderID" provides a list of OCSP responders that the client
trusts. A zero-length "responder_id_list" sequence has the special trusts. A zero-length "responder_id_list" sequence has the special
meaning that the responders are implicitly known to the server, e.g., meaning that the responders are implicitly known to the server, e.g.,
by prior arrangement, or are identfied by the certificates used by by prior arrangement, or are identfied by the certificates used by
the server. "Extensions" is a DER encoding [CCITT.X690.2002] of the the server. "Extensions" is a DER encoding [CCITT.X690.2002] of the
OCSP request extensions. 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 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 DER-encoded zero-length ASN.1 SEQUENCE,
valid for the "Extensions" type). 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 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 items in the list of CertificateStatusRequestItemV2 entries are The items in the list of CertificateStatusRequestItemV2 entries are
in order of the client's preference (favorite choice first). in order of the client's preference (favorite choice first).
skipping to change at page 6, line 9 skipping to change at page 6, line 11
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 (originally certificate by sending a "CertificateStatus" message (originally
defined by [RFC6066]) immediately after the [RFC5246] (Section 7.4.2) defined by [RFC6066]) immediately after the [RFC5246] (Section 7.4.2)
"Certificate" message (and before any "ServerKeyExchange" or "Certificate" message (and before any "ServerKeyExchange" or
"CertificateRequest" messages). If a server returns a "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" (defined in [RFC6066]) as
[RFC6066]): follows (updated from the definition in [RFC6066]):
struct { struct {
CertificateStatusType status_type; CertificateStatusType status_type;
select (status_type) { select (status_type) {
case ocsp: OCSPResponse; case ocsp: OCSPResponse;
case ocsp_multi: OCSPResponseList; case ocsp_multi: OCSPResponseList;
} response; } response;
} CertificateStatus; } CertificateStatus;
opaque OCSPResponse<0..2^24-1>; opaque OCSPResponse<0..2^24-1>;
skipping to change at page 7, line 41 skipping to change at page 7, line 24
client hello message and sent a corresponding "status_request" or client hello message and sent a corresponding "status_request" or
"status_request_v2" extension in the server hello message. "status_request_v2" extension in the server hello message.
Clients requesting an OCSP response and receiving one or more OCSP Clients requesting an OCSP response and receiving one or more OCSP
responses in a "CertificateStatus" message MUST check the OCSP responses in a "CertificateStatus" message MUST check the OCSP
response(s) and abort the handshake if the response is a revoked response(s) and abort the handshake if the response is a revoked
status or other unacceptable responses (as determined by client status or other unacceptable responses (as determined by client
policy), with a bad_certificate_status_response(113) alert. This policy), with a bad_certificate_status_response(113) alert. This
alert is always fatal. alert is always fatal.
If the response is inconclusive, then the client MAY decide to allow If the OCSP response received from the server does not result in a
the connection if it believes it will have the opportunity to check definite "good" or "revoked" status, it is inconclusive. A TLS
the validity of the certificate through another means, e.g., by client in such a case MAY check the validity of the server
directly querying the issuer's CRL or OCSP responders. The client certificate through other means, e.g., by directly querying the
MUST abort the connection if it needs to engage in activities that certificate issuer. If such processing still results in an
require trust in the server, and the server certificate has not been inconclusive response, then the application using the TLS connection
sufficiently validated. An example of where the client might wish to will have to decide whether to close the connection or not. Note
continue is with EAP-TLS, where the client can use another mechanism that this problem cannot be decided by the generic TLS client code
to check the status of a certificate once it obtains network access. without information from the application. If the application doesn't
In this case, the client could continue with the handshake, but it provide any such information, then the client MUST abort the
MUST NOT disclose a username and password until it has fully connection since the server certificate has not been sufficiently
validated the server certificate. 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 3. IANA Considerations
Section 2.1 defines the new TLS Extension status_request_v2 enum, Section 2.1 defines the new TLS Extension status_request_v2 enum,
which should be added to the ExtensionType Values list in the IANA which should be added to the ExtensionType Values list in the IANA
Transport Layer Security (TLS) Extensions registry. Transport Layer Security (TLS) Extensions registry.
Section 2.2 describes a TLS CertificateStatusType Registry to be Section 2.2 describes a TLS CertificateStatusType Registry to be
maintained by the IANA. The new registry is called TLS Certificate maintained by the IANA. The new registry is called TLS Certificate
Status Types and should be defined under the Transport Layer Security Status Types and should be defined under the Transport Layer Security
skipping to change at page 8, line 43 skipping to change at page 8, line 34
If a client requests an OCSP response, it must take into account that If a client requests an OCSP response, it must take into account that
an attacker's server using a compromised key could (and probably an attacker's server using a compromised key could (and probably
would) pretend not to support the extension. In this case, a client would) pretend not to support the extension. In this case, a client
that requires OCSP validation of certificates SHOULD either contact that requires OCSP validation of certificates SHOULD either contact
the OCSP server directly or abort the handshake. the OCSP server directly or abort the handshake.
Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
improve security against attacks that attempt to replay OCSP improve security against attacks that attempt to replay OCSP
responses; see Section 4.4.1 of [RFC2560] for further details. responses; see Section 4.4.1 of [RFC2560] 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 [RFC2560] apply to OCSP requests and The security considerations of [RFC2560] apply to OCSP requests and
responses. responses.
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]
 End of changes. 15 change blocks. 
30 lines changed or deleted 53 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/