< draft-ietf-tls-multiple-cert-status-extension-00.txt		draft-ietf-tls-multiple-cert-status-extension-01.txt >
	Network Working Group Y. Pettersen		Network Working Group Y. Pettersen
	Internet-Draft Opera Software ASA		Internet-Draft Opera Software ASA
	Intended status: Standards Track May 9, 2012		Intended status: Standards Track July 8, 2012
	Expires: November 10, 2012		Expires: January 9, 2013
	The TLS Multiple Certificate Status Request Extension		The TLS Multiple Certificate Status Request Extension
	draft-ietf-tls-multiple-cert-status-extension-00		draft-ietf-tls-multiple-cert-status-extension-01
	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		that a server can use to provide status information (i.e., based on
	can use to provide status information not just about the server's own		the Online Certificate Status Protocol and Server-Based Certificate
	certificate, but also the status of intermediate certificates in the		Validation Protocol) not just about the server's own certificate, but
	chain.		also the status of intermediate certificates in the chain.
	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].
	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 November 10, 2012.		This Internet-Draft will expire on January 9, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 41 ¶		skipping to change at page 2, line 35 ¶
	reduced number of roundtrips and network delays for the client to		reduced number of roundtrips and network delays for the client to
	verify the status of the server's certificate and a reduced load on		verify the status of the server's certificate and a reduced load on
	the certificate issuer's status response servers, thus solving a		the certificate issuer's status response servers, thus solving a
	problem that can become significant when the issued certificate is		problem that can become significant when the issued certificate is
	presented by a frequently visited server.		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 CRLs, thus adding		information through other methods, such as Certificate Revocation
	additional delay. Second, the current format of the extension and		Lists (CRLs), thus adding additional delay. Second, the current
	requirements in the TLS protocol prevents a client from offering the		format of the extension and requirements in the TLS protocol prevents
	server multiple status methods.		a client from offering the server multiple status methods; there are
			two methods available, the Online Certificate Status Protocol (OCSP)
			[RFC2560] and the Server-Based Certificate Validation Protocol (SCVP)
			[RFC5055].
	Many Certification Authorities are now issuing intermediate CA		Many CAs now issue intermediate CA certificates that not only specify
	certificates that not only specify a CRL Distribution Point		the publication point for their CRLs in CRL Distribution Point
	[RFC5280], but also a URL for OCSP [RFC2560] Certificate Status		[RFC5280], but also specify a URL for their OCSP [RFC2560] server in
	requests. Given that client-cached CRLs are frequently out of date,		Authority Information Access [RFC5280]. Given that client-cached
	using OCSP to access up-to-date status information about intermediate		CRLs are frequently out of date, clients would benefit from using
	CA certificates will be of great benefit to clients. The benefit to		OCSP, or other protocols, to access up-to-date status information
	the issuing CA is less clear, as providing the bandwidth for the OCSP		about intermediate CA certificates. The benefit to the issuing CA is
	responder can be costly, especially for CAs with many high-traffic		less clear, as providing the bandwidth for the OCSP responder can be
	subscriber sites, and this cost is a concern for many CAs. There are		costly, especially for CAs with many high-traffic subscriber sites,
	cases where OCSP requests for a single high-traffic site caused		and this cost is a concern for many CAs. There are cases where OCSP
	significant network problems for the issuing CA.		requests for a single high-traffic site caused significant network
			problems for the issuing CA.
	For these reasons, it will be beneficial to use the TLS server to		Clients will benefit from the TLS server providing certificate status
	provide the certificate status information not just for the server		information regardless of type, not just for the server certificate,
	certificate, but also for the intermediate CA certificates. This		but also for the intermediate CA certificates. Combining the status
	will reduce the roundtrips needed to complete the handshake by the		checks into one extension will reduce the roundtrips needed to
	client to just those needed for negotiating the TLS connection.		complete the handshake by the client to just those needed for
	Also, for the Certification Authorities, the load on their servers		negotiating the TLS connection. Also, for the Certification
	will depend on the number of certificates they have issued, not on		Authorities, the load on their servers will depend on the number of
	the number of visitors to those sites.		certificates they have issued, not on the number of visitors to those
			sites.
	For such a new system to be introduced seamlessly, it must be		For such a new system to be introduced seamlessly, clients need to be
	possible for clients to indicate support for the existing OCSP		able to indicate support for the existing OCSP Certificate Status
	Certificate Status method, and a new multiple-OCSP mode.		method and a new multiple-OCSP mode or the new SCVP 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 only		single extension record in the handshake, and the TLS Protocol
	allows a single record in the extension list for any given extension.		[RFC5246] only allows a single record in the extension list for any
	This means that it is not possible for clients to indicate support		given extension. This means that it is not possible for clients to
	for new methods while still supporting older methods, which would		indicate support for new methods while still supporting older
	cause problems for interoperability between newer clients and older		methods, which would cause problems for interoperability between
	servers. This will not just be an issue for the multiple status		newer clients and older servers. This will not just be an issue for
	request mode proposed above, but also for any other future status		the multiple status request mode proposed above, but also for any
	methods that might be introduced. This will be true not just for the		other future status methods that might be introduced. This will be
	current PKIX infrastructure, but also for alternative PKI structures.		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,		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 by using a list of CertificateStatusRequestItem records		implemented using a list of CertificateStatusRequestItem records in
	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
			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].
	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, which uses the
	following value:		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 XX.		[[ EDITOR: The value used for status_request_v2 has been left as
	This value will be assigned when this draft progresses to RFC.]]		"XX". This value will be assigned when this draft progresses to
			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 (i.e., OCSP and
	the status_request_v2 extension to the server in order to use the TLS		SCVP) may send the status_request_v2 extension to the server in order
	handshake to transfer such data instead of downloading it through		to use the TLS handshake to transfer such data instead of downloading
	separate connections. When using this extension, the		it through separate connections. When using this extension, the
	"extension_data" field of the extension SHALL contain a		"extension_data" field of the extension SHALL contain a
	CertificateStatusRequestList where:		CertificateStatusRequestList 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;
			case scvp: SCVPStatusRequest;
	} request;		} request;
	} CertificateStatusRequestItem;		} CertificateStatusRequestItem;
	enum { ocsp(1), ocsp_multi(YY), (255) } CertificateStatusType;		enum {
			ocsp(1), ocsp_multi(YY), scvp (AA),(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;
			struct {
			ResponderID responder_id_list<0..2^16-1>;
			Extensions request_extensions;
			} SCVPStatusRequest;
	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>		CertificateStatusRequestItem certificate_status_req_list<1..2^16-1>
	} CertificateStatusRequestList		} CertificateStatusRequestList
	[[ EDITOR: The value used for ocsp_multi has been left as YY. This		[[ EDITOR: The values used for ocsp_multi and scvp have been left as
	value will be assigned when this draft progresses to RFC.]]		"YY" and "AA", respectively. These values will be assigned when this
	In the OCSPStatusRequestItem, the "ResponderIDs" provides a list of		draft progresses to RFC.]]
	OCSP responders that the client trusts. A zero-length
			In the OCSPStatusRequest and SCVPStatusRequest structures, the
			"ResponderIDs" provide a list of OCSP and SCVP responders
			(respectively) that the client trusts. A zero-length
	"responder_id_list" sequence has the special meaning that the		"responder_id_list" sequence has the special meaning that the
	responders are implicitly known to the server, e.g., by prior		responders are implicitly known to the server, e.g., by prior
	arrangement, or are identfied by the certificates used by the server.		arrangement, or are identfied by the certificates used by the server.
	"Extensions" is a DER encoding of OCSP request extensions.		"Extensions" is a DER encoding [CCITT.X690.2002] of the OCSP and SCVP
			request extensions (respectively).
	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] (for OCSP) and [RFC5055] (for SCVP).
	zero-length "request_extensions" value means that there are no		"Extensions" is imported from [RFC5280]. A zero-length
	extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not		"request_extensions" value means that there are no extensions (as
	valid for the "Extensions" type).		opposed to a zero-length ASN.1 SEQUENCE, which is not 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 list of CertificateStatusRequestItem entries MUST be in order of
	preference.		preference.
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 40 ¶
	"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) {
	case ocsp: OCSPResponse;		case ocsp: OCSPResponse;
	case ocsp_multi: OCSPResponseList;		case ocsp_multi: OCSPResponseList;
			case scvp: SCVPResponse;
	} response;		} response;
	} CertificateStatus;		} CertificateStatus;
	opaque OCSPResponse<0..2^24-1>;		opaque OCSPResponse<0..2^24-1>;
			opaque SCVPResponse<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		An "OCSPResponse" element contains a complete, DER-encoded OCSP
	[CCITT.X680.2002] OCSP response (using the ASN.1 [CCITT.X680.2002]		response (using the ASN.1 syntax [CCITT.X680.2002] of type
	type OCSPResponse defined in [RFC2560]). Only one OCSP response,		OCSPResponse as defined in [RFC2560]). Only one OCSP response, with
	with a length of at least one byte, may be sent for status_type		a length of at least one byte, may be sent for status_type "ocsp".
	"ocsp".
			An "SCVPResponse" element contains a complete, DER-encoded SCVP
			response (using the ASN.1 syntax [CCITT.X680.2002] of type CVResponse
			as defined in [RFC5055]). Only one SCVP response, with a length of
			at least one byte, may be sent for status_type "scvp". An SCVP
			response can include the status of intermediate certificates.
	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 7, line 6 ¶		skipping to change at page 7, line 45 ¶
	Note that a server MAY also choose not to send a "CertificateStatus"		Note that a server MAY also choose not to send a "CertificateStatus"
	message, even if it has received a "status_request_v2" extension in		message, even if it has received a "status_request_v2" extension in
	the client hello message and has sent a "status_request_v2" extension		the client hello message and has sent a "status_request_v2" extension
	in the server hello message. Additionally, note that that a server		in the server hello message. Additionally, note that that a server
	MUST NOT send the "CertificateStatus" message unless it received		MUST NOT send the "CertificateStatus" message unless it received
	either a "status_request" or "status_request_v2" extension in the		either a "status_request" or "status_request_v2" extension in the
	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 a certificate response and receiving either one or
	responses in a "CertificateStatus" message MUST check the OCSP		more OCSP responses or a SCVP response in a "CertificateStatus"
	response(s) and abort the handshake, if the response is a revoked		message MUST check the response(s) and abort the handshake, if the
	status or is otherwise not satisfactory with a		response is a revoked status or is otherwise not satisfactory with a
	bad_certificate_status_response(113) alert. This alert is always		bad_certificate_status_response(113) alert. This alert is always
	fatal.		fatal.
	[[Open issue: At least one reviewer has suggested that the client		[[Open issue: At least one reviewer has suggested that the client
	should treat an unsatisfactory (non-revoked) response as an empty		should treat an unsatisfactory (non-revoked) response as an empty
	response for that particular response and fall back to the		response for that particular response and fall back to the
	alternative method described above]]		alternative method described above]]
	3. IANA Considerations		3. IANA Considerations
	skipping to change at page 7, line 40 ¶		skipping to change at page 8, line 30 ¶
	4. Security Considerations		4. Security Considerations
	General Security Considerations for TLS Extensions are covered in		General Security Considerations for TLS Extensions are covered in
	[RFC5246]. Security Considerations for the particular extension		[RFC5246]. Security Considerations for the particular extension
	specified in this document are given below. In general, implementers		specified in this document are given below. In general, implementers
	should continue to monitor the state of the art and address any		should continue to monitor the state of the art and address any
	weaknesses identified.		weaknesses identified.
	4.1. Security Considerations for status_request_v2		4.1. Security Considerations for status_request_v2
	If a client requests an OCSP response, it must take into account that		If a client requests an OCSP or SCVP response, it must take into
	an attacker's server using a compromised key could (and probably		account that an attacker's server using a compromised key could (and
	would) pretend not to support the extension. In this case, a client		probably would) pretend not to support the extension. In this case,
	that requires OCSP validation of certificates SHOULD either contact		a client that requires OCSP or SCVP validation of certificates SHOULD
	the OCSP server directly or abort the handshake.		either contact the OCSP or SCVP server directly or abort the
			handshake.
	Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may		Use of the OCSP (id-pkix-ocsp-nonce) or SCVP nonce request extension
	improve security against attacks that attempt to replay OCSP		may improve security against attacks that attempt to replay OCSP or
	responses; see Section 4.4.1 of [RFC2560] for further details.		SCVP responses; see Section 4.4.1 of [RFC2560] and Section 9 of
			[RFC5055] for further details.
			The security considerations of [RFC2560] apply to OCSP requests and
			responses, and the security considerations of [RFC5055] apply to SCVP
			erquests and 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.
			The SCVP status type description is based on text provided by Sean
			Turner.
	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 Recommendation X.680, July 2002.		CCITT Recommendation X.680, July 2002.
	[CCITT.X690.2002]		[CCITT.X690.2002]
	International International Telephone and Telegraph		International International Telephone and Telegraph
	skipping to change at page 8, line 31 ¶		skipping to change at page 9, line 30 ¶
	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.
	[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.		[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
	Adams, "X.509 Internet Public Key Infrastructure Online		Adams, "X.509 Internet Public Key Infrastructure Online
	Certificate Status Protocol - OCSP", RFC 2560, June 1999.		Certificate Status Protocol - OCSP", RFC 2560, June 1999.
			[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
			Polk, "Server-Based Certificate Validation Protocol
			(SCVP)", RFC 5055, December 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
End of changes. 29 change blocks.
	85 lines changed or deleted		127 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/