< draft-ietf-tls-cached-info-12.txt		draft-ietf-tls-cached-info-13.txt >
	TLS S. Santesson		TLS S. Santesson
	Internet-Draft 3xA Security AB		Internet-Draft 3xA Security AB
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: January 16, 2013 Nokia Siemens Networks		Expires: March 16, 2013 Nokia Siemens Networks
	July 15, 2012		September 12, 2012
	Transport Layer Security (TLS) Cached Information Extension		Transport Layer Security (TLS) Cached Information Extension
	draft-ietf-tls-cached-info-12.txt		draft-ietf-tls-cached-info-13.txt
	Abstract		Abstract
	Transport Layer Security (TLS) handshakes often include fairly static		Transport Layer Security (TLS) handshakes often include fairly static
	information, such as the server certificate and a list of trusted		information, such as the server certificate and a list of trusted
	Certification Authorities (CAs). This information can be of		Certification Authorities (CAs). This information can be of
	considerable size, particularly if the server certificate is bundled		considerable size, particularly if the server certificate is bundled
	with a complete certificate path (including all intermediary		with a complete certificate path (including all intermediary
	certificates up to the trust anchor public key).		certificates up to the trust anchor public key).
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 January 16, 2013.		This Internet-Draft will expire on March 16, 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 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	opaque ASN.1Cert<1..2^24-1>;		opaque ASN.1Cert<1..2^24-1>;
	struct {		struct {
	ASN.1Cert certificate_list<0..2^24-1>;		ASN.1Cert certificate_list<0..2^24-1>;
	} Certificate;		} Certificate;
	By using the extension defined in this document the following		By using the extension defined in this document the following
	information is sent:		information is sent:
	struct {		struct {
	CachedObject ASN.1Cert<1..2^24-1>;		CachedObject cached_objects<1..2^24-1>;
	} Certificate;		} Certificate;
	The opaque ASN.1Cert structure is replaced with the CachedObject		The certificate_list vector of opaque ASN.1Cert elements in the
	structure defined in this document.		original syntax is replaced with a vector holding CachedObject
			structures as defined in this document.
	Note: [I-D.ietf-tls-oob-pubkey] allows a PKIX certificate containing		Note: [I-D.ietf-tls-oob-pubkey] allows a PKIX certificate containing
	only the SubjectPublicKeyInfo instead of the full information		only the SubjectPublicKeyInfo instead of the full information
	typically found in a certificate. Hence, when this specification is		typically found in a certificate. Hence, when this specification is
	used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated		used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated
	certificate type is a raw public key then the TLS server sends the		certificate type is a raw public key then the TLS server sends the
	hashed Certificate payload that contains a ASN.1Cert structure of the		hashed Certificate payload that contains a ASN.1Cert structure of the
	SubjectPublicKeyInfo.		SubjectPublicKeyInfo.
	4.2. Fingerprint for Trusted CAs		4.2. Fingerprint for Trusted CAs
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 10 ¶
	DistinguishedName certificate_authorities<0..2^16-1>;		DistinguishedName certificate_authorities<0..2^16-1>;
	} CertificateRequest;		} CertificateRequest;
	By using the extension defined in this document the following		By using the extension defined in this document the following
	information is sent:		information is sent:
	struct {		struct {
	ClientCertificateType certificate_types<1..2^8-1>;		ClientCertificateType certificate_types<1..2^8-1>;
	SignatureAndHashAlgorithm		SignatureAndHashAlgorithm
	supported_signature_algorithms<2^16-1>;		supported_signature_algorithms<2^16-1>;
	CachedObject DistinguishedName<1..2^16-1>;		CachedObject cached_objects<1..2^16-1>;
	} CertificateRequest;		} CertificateRequest;
	The opaque DistinguishedName structure is replaced with the		The certificate_authorities vector of opaque DistinguishedName
	CachedObject structure defined in this document.		elements in the original syntax is replaced with a vector holding
			CachedObject structures as defined in this document.
	5. Example		5. Example
	Figure 1 illustrates an example exchange using the TLS cached info		Figure 1 illustrates an example exchange using the TLS cached info
	extension. In the normal TLS handshake exchange shown in flow (A)		extension. In the normal TLS handshake exchange shown in flow (A)
	the TLS server provides its certificate in the Certificate payload to		the TLS server provides its certificate in the Certificate payload to
	the client, see step [1]. This allows the client to store the		the client, see step [1]. This allows the client to store the
	certificate for future use. After some time the TLS client again		certificate for future use. After some time the TLS client again
	interacts with the same TLS server and makes use of the TLS cached		interacts with the same TLS server and makes use of the TLS cached
	info extension, as shown in flow (B). The TLS client indicates		info extension, as shown in flow (B). The TLS client indicates
	skipping to change at page 15, line 25 ¶		skipping to change at page 15, line 25 ¶
	[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.
	[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.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-tls-oob-pubkey]		[I-D.ietf-tls-oob-pubkey]
	Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.		Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
	Tschofenig, "TLS Out-of-Band Public Key Validation",		Tschofenig, "Out-of-Band Public Key Validation for
	draft-ietf-tls-oob-pubkey-03 (work in progress),		Transport Layer Security", draft-ietf-tls-oob-pubkey-04
	April 2012.		(work in progress), July 2012.
	[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.
	[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object		[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
	Workshop", RFC 6574, April 2012.		Workshop", RFC 6574, April 2012.
	Authors' Addresses		Authors' Addresses
End of changes. 8 change blocks.
	13 lines changed or deleted		15 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/