< draft-ietf-tls-multiple-cert-status-extension-03.txt		draft-ietf-tls-multiple-cert-status-extension-04.txt >
	Network Working Group Y. Pettersen		Network Working Group Y. Pettersen
	Internet-Draft January 9, 2013		Internet-Draft February 6, 2013
	Intended status: Standards Track		Intended status: Standards Track
	Expires: July 13, 2013		Expires: August 10, 2013
	The TLS Multiple Certificate Status Request Extension		The TLS Multiple Certificate Status Request Extension
	draft-ietf-tls-multiple-cert-status-extension-03		draft-ietf-tls-multiple-cert-status-extension-04
	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 July 13, 2013.		This Internet-Draft will expire on August 10, 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 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	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;
	} CertificateStatusRequestItem;		} CertificateStatusRequestItem;
	enum { ocsp(1), ocsp_multi(YY), (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 {
	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
	value will be assigned when this draft progresses to RFC.]]
	In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP		In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
	responders that the client trusts. A zero-length "responder_id_list"		responders that the client trusts. A zero-length "responder_id_list"
	sequence has the special meaning that the responders are implicitly		sequence has the special meaning that the responders are implicitly
	known to the server, e.g., by prior arrangement, or are identfied by		known to the server, e.g., by prior arrangement, or are identfied by
	the certificates used by the server. "Extensions" is a DER encoding		the certificates used by the server. "Extensions" is a DER encoding
	[CCITT.X690.2002] of the OCSP request extensions.		[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
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 29 ¶
	continue is with EAP-TLS, where the client can use another mechanism		continue is with EAP-TLS, where the client can use another mechanism
	to check the status of a certificate once it obtains network access.		to check the status of a certificate once it obtains network access.
	In this case, the client could continue with the handshake, but it		In this case, the client could continue with the handshake, but it
	would be inappropriate for the client to disclose a username and		would be inappropriate for the client to disclose a username and
	password until it has fully validated the server certificate.		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.		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. CertificateStatusType values are 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 [RFC5226]. The initial		assigned via IETF Review as defined in [RFC5226]. The initial
	registry corresponds to the definition of "ExtensionType" in		registry corresponds to the definition of "ExtensionType" in
	Section 2.2.		Section 2.2.
			Value Description Reference
			1 ocsp [This RFC]
			2 ocsp_multi [This RFC]
	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
End of changes. 9 change blocks.
	10 lines changed or deleted		13 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/