< draft-ietf-tls-multiple-cert-status-extension-02.txt		draft-ietf-tls-multiple-cert-status-extension-03.txt >
	Network Working Group Y. Pettersen		Network Working Group Y. Pettersen
	Internet-Draft Opera Software ASA		Internet-Draft January 9, 2013
	Intended status: Standards Track October 19, 2012		Intended status: Standards Track
	Expires: April 22, 2013		Expires: July 13, 2013
	The TLS Multiple Certificate Status Request Extension		The TLS Multiple Certificate Status Request Extension
	draft-ietf-tls-multiple-cert-status-extension-02		draft-ietf-tls-multiple-cert-status-extension-03
	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.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 April 22, 2013.		This Internet-Draft will expire on July 13, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	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 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 is otherwise not satisfactory with a		status or other unacceptable responses (as determined by client
	bad_certificate_status_response(113) alert. This alert is always		policy), with a bad_certificate_status_response(113) alert. This
	fatal.		alert is always fatal.
	[[Open issue: At least one reviewer has suggested that the client		If the response is inconclusive, then the client MAY decide to allow
	should treat an unsatisfactory (non-revoked) response as an empty		the connection if it believes it will have the opportunity to check
	response for that particular response and fall back to the		the validity of the certificate through another means, e.g., by
	alternative method described above]]		directly querying the issuer's CRL or OCSP responders. The client
			MUST abort the connection if it needs to engage in activities that
			require trust in the server, and the server certificate has not been
			sufficiently validated. An example of where the client might wish to
			continue is with EAP-TLS, where the client can use another mechanism
			to check the status of a certificate once it obtains network access.
			In this case, the client could continue with the handshake, but it
			would be inappropriate for the client to 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
	TLS category after IETF Concensus has decided to add the value.		TLS category after IETF Concensus has decided to add the value.
	Section 2.2 describes a TLS CertificateStatusType Registry to be		Section 2.2 describes a TLS CertificateStatusType Registry to be
	maintained by the IANA. CertificateStatusType values are to be		maintained by the IANA. CertificateStatusType values are to be
	assigned via IETF Review as defined in [RFC5226]. The initial		assigned via IETF Review as defined in [RFC5226]. The initial
	skipping to change at page 9, line 8 ¶		skipping to change at page 9, line 11 ¶
	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
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:		[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
	Extension Definitions", RFC 6066, January 2011.		Extension Definitions", RFC 6066, January 2011.
	Author's Address		Author's Address
	Yngve N. Pettersen		Yngve N. Pettersen
	Opera Software ASA
	Email: yngve@opera.com		Email: yngve@spec-work.net
End of changes. 8 change blocks.
	15 lines changed or deleted		22 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/