One document matched: draft-ietf-tls-multiple-cert-status-extension-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-tls-multiple-cert-status-extension-08"
ipr="pre5378Trust200902">
<front>
<title abbrev="Multiple Certificate Status Extension">The TLS Multiple
Certificate Status Request Extension</title>
<author fullname="Yngve N. Pettersen" initials="Y." surname="Pettersen">
<organization/>
<address>
<email>yngve@spec-work.net</email>
</address>
</author>
<date day="12" month="April" year="2013"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Transport Layer Security (TLS) Extension <xref target="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.</t>
<t>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.</t>
<t>Many CAs are now issuing intermediate CA certificates that not only
specify the publication point for their CRLs in a CRL Distribution Point
<xref target="RFC5280"/>, but also specify a URL for their OCSP <xref
target="I-D.ietf-pkix-rfc2560bis"/> server in Authority Information
Access <xref target="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.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="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 <xref target="RFC5280"/>, but also for
alternative PKI structures.</t>
<t>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.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Presentation language">
<t>This document defines protocol structures using the same
conventions and presentation language as defined in Section 4 of <xref
target="RFC5246"/>.</t>
</section>
</section>
<section title="Multiple Certificate Status Extension">
<t/>
<section anchor="NewExtension" title="New extension">
<t>The extension defined by this document is indicated by the
"status_request_v2" in the ExtensionType enum (originally defined by
<xref target="RFC6066"/>), which uses the following value:</t>
<figure>
<artwork><![CDATA[
enum {
status_request_v2(XX), (65535)
} ExtensionType;]]></artwork>
</figure>
<t>[[ EDITOR: The value used for status_request_v2 has been left as
"XX". This value will be assigned when this draft progresses to
RFC.]]</t>
<t/>
</section>
<section anchor="MultiRecord"
title="Multiple Certificate Status Request record">
<t>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<xref target="RFC5246"/>) of the
extension SHALL contain a CertificateStatusRequestListV2 where:</t>
<figure>
<artwork><![CDATA[
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;
]]></artwork>
</figure>
<t>In the OCSPStatusRequest (originally defined by <xref
target="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
<xref target="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.</t>
<t>Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
defined in <xref target="I-D.ietf-pkix-rfc2560bis"/>. "Extensions" is
imported from <xref target="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).</t>
<t>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.</t>
<t>In the case of the "id-pkix-ocsp-nonce" OCSP extension, <xref
target="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 <xref
target="I-D.ietf-pkix-rfc2560bis"/>.</t>
<t>The items in the list of CertificateStatusRequestItemV2 entries are
in order of the client's preference (favorite choice first).</t>
<t>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.</t>
<t>The server returns a certificate status response along with its
certificate by sending a "CertificateStatus" message (originally
defined by <xref target="RFC6066"/>) immediately after the <xref
target="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
<xref target="RFC6066"/>) as follows (updated from the definition in
<xref target="RFC6066"/>):</t>
<figure>
<artwork><![CDATA[
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;
]]></artwork>
</figure>
<t>An "OCSPResponse" element (originally defined by <xref
target="RFC6066"/>) contains a complete, DER-encoded OCSP response
(using the ASN.1 <xref target="CCITT.X680.2002"/> type OCSPResponse
defined in <xref target="I-D.ietf-pkix-rfc2560bis"/>). Only one OCSP
response, with a length of at least one byte, may be sent for
status_type "ocsp".</t>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t><xref target="NewExtension"/> 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.</t>
<t><xref target="MultiRecord"/> 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 <xref target="RFC5226"/>. The
initial registry corresponds to the definition of "ExtensionType" in
<xref target="MultiRecord"/>.</t>
<t/>
<figure>
<artwork><![CDATA[Value Description Reference
1 ocsp [This RFC]
2 ocsp_multi [This RFC]]]></artwork>
</figure>
<t/>
</section>
<section anchor="Security" title="Security Considerations">
<t>General Security Considerations for TLS Extensions are covered in
<xref target="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.</t>
<section title="Security Considerations for status_request_v2">
<t>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.</t>
<t>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 <xref
target="I-D.ietf-pkix-rfc2560bis"/> for further details.</t>
<t>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.</t>
<t>The security considerations of <xref
target="I-D.ietf-pkix-rfc2560bis"/> apply to OCSP requests and
responses.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document is based on <xref target="RFC6066"/> authored by Donald
Eastlake 3rd.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.draft-ietf-pkix-rfc2560bis-17"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.5246"?>
<?rfc include="reference.RFC.5280"?>
<?rfc include="reference.RFC.6066"?>
<?rfc include='reference.CCITT.X680.2002'?>
<?rfc include='reference.CCITT.X690.2002'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2560'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:46 |