draft-ietf-tls-cached-info-20.txt		draft-ietf-tls-cached-info-21.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: April 21, 2016 ARM Ltd.		Expires: June 23, 2016 ARM Ltd.
	October 19, 2015		December 21, 2015
	Transport Layer Security (TLS) Cached Information Extension		Transport Layer Security (TLS) Cached Information Extension
	draft-ietf-tls-cached-info-20.txt		draft-ietf-tls-cached-info-21.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 chain (i.e., the certificates of		with a complete certificate chain (i.e., the certificates of
	intermediate CAs up to the root CA).		intermediate CAs up to the root CA).
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	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 21, 2016.		This Internet-Draft will expire on June 23, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 30		skipping to change at page 2, line 30
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10		8.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10
	8.2. New Registry for CachedInformationType . . . . . . . . . 10		8.2. New Registry for CachedInformationType . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12		Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Reducing the amount of information exchanged during a Transport Layer		Reducing the amount of information exchanged during a Transport Layer
	Security handshake to a minimum helps to improve performance in		Security handshake to a minimum helps to improve performance in
	environments where devices are connected to a network with a low		environments where devices are connected to a network with a low
	bandwidth, and lossy radio technology. With Internet of Things such		bandwidth, and lossy radio technology. With Internet of Things such
	environments exist, for example, when devices use IEEE 802.15.4 or		environments exist, for example, when devices use IEEE 802.15.4 or
	Bluetooth Smart. For more information about the challenges with		Bluetooth Smart. For more information about the challenges with
	smart object deployments please see [RFC6574].		smart object deployments please see [RFC6574].
	skipping to change at page 3, line 6		skipping to change at page 3, line 6
	handshake.		handshake.
	A typical example exchange may therefore look as follows. First, the		A typical example exchange may therefore look as follows. First, the
	client and the server executes the full TLS handshake. The client		client and the server executes the full TLS handshake. The client
	then caches the certificate provided by the server. When the TLS		then caches the certificate provided by the server. When the TLS
	client connects to the TLS server some time in the future, without		client connects to the TLS server some time in the future, without
	using session resumption, it then attaches the cached_info extension		using session resumption, it then attaches the cached_info extension
	defined in this document to the client hello message to indicate that		defined in this document to the client hello message to indicate that
	it had cached the certificate, and it provides the fingerprint of it.		it had cached the certificate, and it provides the fingerprint of it.
	If the server's certificate has not changed then the TLS server does		If the server's certificate has not changed then the TLS server does
	not need to send its' certificate and the corresponding certificate		not need to send its certificate and the corresponding certificate
	chain again. In case information has changed, which can be seen from		chain again. In case information has changed, which can be seen from
	the fingerprint provided by the client, the certificate payload is		the fingerprint provided by the client, the certificate payload is
	transmitted to the client to allow the client to update the cache.		transmitted to the client to allow the client to update the cache.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 4, line 20		skipping to change at page 4, line 20
	select (type) {		select (type) {
	case client:		case client:
	CachedInformationType type;		CachedInformationType type;
	opaque hash_value<1..255>;		opaque hash_value<1..255>;
	case server:		case server:
	CachedInformationType type;		CachedInformationType type;
	} body;		} body;
	} CachedObject;		} CachedObject;
	struct {		struct {
	CachedObject cached_info<1..2^16-1>;		CachedObject cached_info<1..2^8-1>;
	} CachedInformation;		} CachedInformation;
	This document defines the following two types:		This document defines the following two types:
	'cert' Type for not sending the complete Server Certificate Message:		'cert' Type for not sending the complete Server Certificate Message:
	With the type field set to 'cert', the client MUST include the		With the type field set to 'cert', the client MUST include the
	fingerprint of the Certificate message in the hash_value field.		fingerprint of the Certificate message in the hash_value field.
	For this type the fingerprint MUST be calculated using the		For this type the fingerprint MUST be calculated using the
	procedure described in Section 5 with the Certificate message as		procedure described in Section 5 with the Certificate message as
	input data.		input data.
	'cert_req' Type for not sending the complete CertificateRequest		'cert_req' Type for not sending the complete CertificateRequest
	Message:		Message:
	With the type set to 'cert_req', the client MUST include the		With the type set to 'cert_req', the client MUST include the
	fingerprint of the CertificateRequest message in the hash_value		fingerprint of the CertificateRequest message in the hash_value
	field. For this type the fingerprint MUST be calculated using the		field. For this type the fingerprint MUST be calculated using the
	procedure described in Section 5 with the CertificateRequest		procedure described in Section 5 with the CertificateRequest
	message as input data..		message as input data.
	New cached info types can be added following the policy described in		New cached info types can be added following the policy described in
	the IANA considerations section, see Section 8. New message digest		the IANA considerations section, see Section 8. New message digest
	algorithms for use with these types can also be added by registering		algorithms for use with these types can also be added by registering
	a new type that makes use of the updated message digest algorithm.		a new type that makes use of the updated message digest algorithm.
	There are no specific requirements for the use of specific hash		There are no specific requirements for the use of specific hash
	algorithms but for practical reason it is useful to re-use algorithms		algorithms but for practical reason it is useful to re-use algorithms
	already available with TLS ciphersuites to avoid additional code and		already available with TLS ciphersuites to avoid additional code and
	to keep the collision probably low.		to keep the collision probably low.
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	A server supporting this extension MAY include the "cached_info"		A server supporting this extension MAY include the "cached_info"
	extension in the (extended) server hello. By returning the		extension in the (extended) server hello. By returning the
	"cached_info" extension the server indicates that it supports the		"cached_info" extension the server indicates that it supports the
	cached info types. For each indicated cached info type the server		cached info types. For each indicated cached info type the server
	MUST alter the transmission of respective payloads, according to the		MUST alter the transmission of respective payloads, according to the
	rules outlined with each type. If the server includes the extension		rules outlined with each type. If the server includes the extension
	it MUST only include CachedObjects of a type also supported by the		it MUST only include CachedObjects of a type also supported by the
	client (as expressed in the client hello). For example, if a client		client (as expressed in the client hello). For example, if a client
	indicates support for 'cert' and 'cert_req' then the server cannot		indicates support for 'cert' and 'cert_req' then the server cannot
	respond with a "cached_info" attribute containing support for ('foo-		respond with a "cached_info" attribute containing support for ('foo-
	bar'.		bar').
	Since the client includes a fingerprint of information it cached (for		Since the client includes a fingerprint of information it cached (for
	each indicated type) the server is able to determine whether cached		each indicated type) the server is able to determine whether cached
	information is stale. If the server supports this specification and		information is stale. If the server supports this specification and
	notices a mismatch between the data cached by the client and its own		notices a mismatch between the data cached by the client and its own
	information then the server MUST include the information in full and		information then the server MUST include the information in full and
	MUST NOT list the respective type in the "cached_info" extension.		MUST NOT list the respective type in the "cached_info" extension.
	Note: If a server is part of a hosting environment then the client		Note: If a server is part of a hosting environment then the client
	may have cached multiple data items for a single server. To allow		may have cached multiple data items for a single server. To allow
	skipping to change at page 6, line 15		skipping to change at page 6, line 15
	o The 'cert' cached info extension is enabled (for example, a policy		o The 'cert' cached info extension is enabled (for example, a policy
	allows the use of this extension).		allows the use of this extension).
	o The server compared the value in the hash_value field of the		o The server compared the value in the hash_value field of the
	client-provided "cached_info" extension with the fingerprint of		client-provided "cached_info" extension with the fingerprint of
	the Certificate message it normally sends to clients. This check		the Certificate message it normally sends to clients. This check
	ensures that the information cached by the client is current. The		ensures that the information cached by the client is current. The
	procedure for calculating the fingerprint is described in		procedure for calculating the fingerprint is described in
	Section 5.		Section 5.
	The original Certificate handshake message syntax is defined in RFC		The original Certificate handshake message syntax is defined in
	5246 [RFC5246] and has been extended with RFC 7250 [RFC7250]. RFC		[RFC5246] and has been extended with [RFC7250]. RFC 7250 allows the
	7250 allows the certificate payload to contain only the		certificate payload to contain only the SubjectPublicKeyInfo instead
	SubjectPublicKeyInfo instead of the full information typically found		of the full information typically found in a certificate. Hence,
	in a certificate. Hence, when this specification is used in		when this specification is used in combination with [RFC7250] and the
	combination with [RFC7250] and the negotiated certificate type is a		negotiated certificate type is a raw public key then the TLS server
	raw public key then the TLS server omits sending a Certificate		omits sending a Certificate payload that contains an ASN.1
	payload that contains an ASN.1 Certificate structure with the		Certificate structure with the included SubjectPublicKeyInfo rather
	included SubjectPublicKeyInfo rather than the full certificate chain.		than the full certificate chain. As such, this extension is
	As such, this extension is compatible with the raw public key		compatible with the raw public key extension defined in RFC 7250.
	extension defined in RFC 7250.		Note: We assume that the server implementation is able to select the
			appropriate certificate or SubjectPublicKeyInfo from the received
			hash value. If the SNI extension is used by the client then the
			server has additional information to guide the selection of the
			appropriate cached info.
	When the cached info specification is used then a modified version of		When the cached info specification is used then a modified version of
	the Certificate message is exchanged. The modified structure is		the Certificate message is exchanged. The modified structure is
	shown in Figure 1.		shown in Figure 1.
	struct {		struct {
	opaque hash_value[1..255];		opaque hash_value[1..255];
	} Certificate;		} Certificate;
	Figure 1: Cached Info Certificate Message.		Figure 1: Cached Info Certificate Message.
	skipping to change at page 7, line 11		skipping to change at page 7, line 15
	o The server compared the value in the hash_value field of the		o The server compared the value in the hash_value field of the
	client-provided "cached_info" extension with the fingerprint of		client-provided "cached_info" extension with the fingerprint of
	the CertificateRequest message it normally sends to clients. This		the CertificateRequest message it normally sends to clients. This
	check ensures that the information cached by the client is		check ensures that the information cached by the client is
	current. The procedure for calculating the fingerprint is		current. The procedure for calculating the fingerprint is
	described in Section 5.		described in Section 5.
	o The server wants to request a certificate from the client.		o The server wants to request a certificate from the client.
	The original CertificateRequest handshake message syntax is defined		The original CertificateRequest handshake message syntax is defined
	in RFC 5246 [RFC5246]. The modified structure of the		in [RFC5246]. The modified structure of the CertificateRequest
	CertificateRequest message is shown in Figure 2.		message is shown in Figure 2.
	struct {		struct {
	opaque hash_value<1..255>;		opaque hash_value<1..255>;
	} CertificateRequest;		} CertificateRequest;
	Figure 2: Cached Info CertificateRequest Message.		Figure 2: Cached Info CertificateRequest Message.
	The CertificateRequest payload is the input parameter to the		The CertificateRequest payload is the input parameter to the
	fingerprint calculation described in Section 5.		fingerprint calculation described in Section 5.
	5. Fingerprint Calculation		5. Fingerprint Calculation
	The fingerprint MUST be computed as follows:		The fingerprint MUST be computed as follows:
	1. Compute the SHA-256 [RFC4634] hash of the input data. The input		1. Compute the SHA-256 [RFC6234] hash of the input data. The input
	data depends on the cached info type. This document defines two		data depends on the cached info type. This document defines two
	cached info types, described in Section 4.1 and in Section 4.2.		cached info types, described in Section 4.1 and in Section 4.2.
	Note that the computed hash only covers the input data structure		Note that the computed hash only covers the input data structure
	(and not any type and length information of the record layer).		(and not any type and length information of the record layer).
			Appendix A shows an example.
	2. Truncate the output of the SHA-256 hash. When a hash value is		2. Truncate the output of the SHA-256 hash. When a hash value is
	truncated to 32 bits, the leftmost 32 bits (that is, the most		truncated to 32 bits, the leftmost 32 bits (that is, the most
	significant 32 bits in network byte order) from the binary		significant 32 bits in network byte order) from the binary
	representation of the hash value MUST be used as the truncated		representation of the hash value MUST be used as the truncated
	value. An example of a 256-bit hash output truncated to 32 bits		value. An example of a 256-bit hash output truncated to 32 bits
	is shown in Figure 3.		is shown in Figure 3.
	256-bit hash:		256-bit hash:
	0x265357902fe1b7e2a04b897c6025d7a2265357902fe1b7e2a04b897c6025d7a2		0x265357902fe1b7e2a04b897c6025d7a2265357902fe1b7e2a04b897c6025d7a2
	skipping to change at page 8, line 25		skipping to change at page 8, line 36
	has to fall back to a full exchange. (2) If the attacker manages to		has to fall back to a full exchange. (2) If the attacker manages to
	inject a fingerprint that refers to data the client has not cached		inject a fingerprint that refers to data the client has not cached
	then the exchange will fail later when the client continues with the		then the exchange will fail later when the client continues with the
	handshake and aims to verify the digital signature. The signature		handshake and aims to verify the digital signature. The signature
	verification will fail since the public key cached by the client will		verification will fail since the public key cached by the client will
	not correspond to the private key that was used by server to sign the		not correspond to the private key that was used by server to sign the
	message.		message.
	6. Example		6. Example
	Figure 4 illustrates an example exchange using the TLS cached info		In the regular, full TLS handshake exchange, shown in Figure 4, the
	extension. In the normal TLS handshake exchange shown in flow (A)		TLS server provides its certificate in the Certificate payload to the
	the TLS server provides its certificate in the Certificate payload to		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 Figure 5. The TLS client indicates
	support for this specification via the "cached_info" extension, see		support for this specification via the "cached_info" extension, see
	[2], and indicates that it has stored the certificate from the		step (2), and indicates that it has stored the certificate from the
	earlier exchange (by indicating the 'cert' type). With [3] the TLS		earlier exchange (by indicating the 'cert' type). With step (3) the
	server acknowledges the supports of the 'cert' type and by including		TLS server acknowledges the supports of the 'cert' type and by
	the value in the server hello informs the client that the content of		including the value in the server hello informs the client that the
	the certificate payload contains the fingerprint of the certificate		content of the certificate payload contains the fingerprint of the
	instead of the RFC 5246-defined payload of the certificate message in		certificate instead of the RFC 5246-defined payload of the
	message [4].		certificate message in step (4).
	(A) Initial (full) Exchange
	ClientHello ->		ClientHello ->
	<- ServerHello		<- ServerHello
	Certificate* // [1]		Certificate* // (1)
	ServerKeyExchange*		ServerKeyExchange*
	CertificateRequest*		CertificateRequest*
	ServerHelloDone		ServerHelloDone
	Certificate*		Certificate*
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify*		CertificateVerify*
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished ->		Finished ->
	<- [ChangeCipherSpec]		<- [ChangeCipherSpec]
	Finished		Finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	(B) TLS Cached Extension Usage		Figure 4: Example Message Exchange: Initial (full) Exchange.
	ClientHello		ClientHello
	cached_info=(cert) -> // [2]		cached_info=(cert) -> // (2)
	<- ServerHello		<- ServerHello
	cached_info=(cert) [3]		cached_info=(cert) (3)
	Certificate [4]		Certificate (4)
	ServerKeyExchange*		ServerKeyExchange*
	ServerHelloDone		ServerHelloDone
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify*		CertificateVerify*
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished ->		Finished ->
	<- [ChangeCipherSpec]		<- [ChangeCipherSpec]
	Finished		Finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	Figure 4: Example Message Exchange		Figure 5: Example Message Exchange: TLS Cached Extension Usage.
	7. Security Considerations		7. Security Considerations
	This specification defines a mechanism to reference stored state		This specification defines a mechanism to reference stored state
	using a fingerprint. Sending a fingerprint of cached information in		using a fingerprint. Sending a fingerprint of cached information in
	an unencrypted handshake, as the client and server hello is, may		an unencrypted handshake, as the client and server hello is, may
	allow an attacker or observer to correlate independent TLS exchanges.		allow an attacker or observer to correlate independent TLS exchanges.
	While some information elements used in this specification, such as		While some information elements used in this specification, such as
	server certificates, are public objects and usually do not contain		server certificates, are public objects and usually do not contain
	sensitive information, other not yet defined types may. Those who		sensitive information, other not yet defined types may. Those who
	skipping to change at page 10, line 28		skipping to change at page 10, line 26
	initial handshake messages the fingerprints are included in the TLS		initial handshake messages the fingerprints are included in the TLS
	Finish message.		Finish message.
	Clients MUST ensure that they only cache information from legitimate		Clients MUST ensure that they only cache information from legitimate
	sources. For example, when the client populates the cache from a TLS		sources. For example, when the client populates the cache from a TLS
	exchange then it must only cache information after the successful		exchange then it must only cache information after the successful
	completion of a TLS exchange to ensure that an attacker does not		completion of a TLS exchange to ensure that an attacker does not
	inject incorrect information into the cache. Failure to do so allows		inject incorrect information into the cache. Failure to do so allows
	for man-in-the-middle attacks.		for man-in-the-middle attacks.
	Security consideratios for the fingerprint calculation are discussed		Security considerations for the fingerprint calculation are discussed
	in Section 5.		in Section 5.
	8. IANA Considerations		8. IANA Considerations
	8.1. New Entry to the TLS ExtensionType Registry		8.1. New Entry to the TLS ExtensionType Registry
	IANA is requested to add an entry to the existing TLS ExtensionType		IANA is requested to add an entry to the existing TLS ExtensionType
	registry, defined in RFC 5246 [RFC5246], for cached_info(TBD) defined		registry, defined in [RFC5246], for cached_info(TBD) defined in this
	in this document.		document.
	8.2. New Registry for CachedInformationType		8.2. New Registry for CachedInformationType
	IANA is requested to establish a registry for TLS		IANA is requested to establish a registry for TLS
	CachedInformationType values. The first entries in the registry are		CachedInformationType values. The first entries in the registry are
	o cert(1)		o cert(1)
	o cert_req(2)		o cert_req(2)
	The policy for adding new values to this registry, following the		The policy for adding new values to this registry, following the
	terminology defined in RFC 5226 [RFC5226], is as follows:		terminology defined in [RFC5226], is as follows:
	o 0-63 (decimal): Standards Action		o 0-63 (decimal): Standards Action
	o 64-223 (decimal): Specification Required
			o 64-223 (decimal): Specification Required
	o 224-255 (decimal): reserved for Private Use		o 224-255 (decimal): reserved for Private Use
	9. Acknowledgments		9. Acknowledgments
	We would like to thank the following persons for your detailed		We would like to thank the following persons for your detailed
	document reviews:		document reviews:
	o Paul Wouters and Nikos Mavrogiannopoulos (December 2011)		o Paul Wouters and Nikos Mavrogiannopoulos (December 2011)
	o Rob Stradling (February 2012)		o Rob Stradling (February 2012)
	o Ondrej Mikle (in March 2012)		o Ondrej Mikle (March 2012)
	o Ilari Liusvaara, Adam Langley, and Eric Rescorla (in July 2014)		o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014)
	o Sean Turner (in August 2014)		o Sean Turner (August 2014)
	o Martin Thomson (in August 2015)		o Martin Thomson (August 2015)
			o Jouni Korhonen (November 2015)
			o Matt Miller (December 2015)
	We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp		We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp
	Bagaria and Eric Rescorla for their feedback regarding the		Bagaria and Eric Rescorla for their feedback regarding the
	fingerprint calculation.		fingerprint calculation.
	Finally, we would like to thank the TLS working group chairs, Sean		Finally, we would like to thank the TLS working group chairs, Sean
	Turner and Joe Salowey, as well as the responsible security area		Turner and Joe Salowey, as well as the responsible security area
	director, Stephen Farrell, for their support.		director, Stephen Farrell, for their support and their reviews.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July
	2006, <http://www.rfc-editor.org/info/rfc4634>.
	[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, DOI 10.17487/		(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
	RFC5246, August 2008,		RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)		[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066, DOI		Extensions: Extension Definitions", RFC 6066, DOI
	10.17487/RFC6066, January 2011,		10.17487/RFC6066, January 2011,
	<http://www.rfc-editor.org/info/rfc6066>.		<http://www.rfc-editor.org/info/rfc6066>.
			[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
			(SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
			10.17487/RFC6234, May 2011,
			<http://www.rfc-editor.org/info/rfc6234>.
	10.2. Informative References		10.2. Informative References
	[ASN.1-Dump]		[ASN.1-Dump]
	Gutmann, P., "ASN.1 Object Dump Program", February 2013,		Gutmann, P., "ASN.1 Object Dump Program", February 2013,
	<http://www.cs.auckland.ac.nz/~pgut001/>.		<http://www.cs.auckland.ac.nz/~pgut001/>.
	[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,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	skipping to change at page 12, line 35		skipping to change at page 12, line 40
	[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,		[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
	Weiler, S., and T. Kivinen, "Using Raw Public Keys in		Weiler, S., and T. Kivinen, "Using Raw Public Keys in
	Transport Layer Security (TLS) and Datagram Transport		Transport Layer Security (TLS) and Datagram Transport
	Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,		Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
	June 2014, <http://www.rfc-editor.org/info/rfc7250>.		June 2014, <http://www.rfc-editor.org/info/rfc7250>.
	Appendix A. Example		Appendix A. Example
	Consider a certificate containing an NIST P256 elliptic curve public		Consider a certificate containing an NIST P256 elliptic curve public
	key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in		key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in
	Figure 5.		Figure 6.
	0 556: SEQUENCE {		0 556: SEQUENCE {
	4 434: SEQUENCE {		4 434: SEQUENCE {
	8 3: [0] {		8 3: [0] {
	10 1: INTEGER 2		10 1: INTEGER 2
	: }		: }
	13 1: INTEGER 13		13 1: INTEGER 13
	16 10: SEQUENCE {		16 10: SEQUENCE {
	18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)		18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
	: }		: }
	skipping to change at page 15, line 31		skipping to change at page 15, line 36
	: 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20		: 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20
	509 49: INTEGER		509 49: INTEGER
	: 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA		: 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA
	: 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC		: 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC
	: 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57		: 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57
	: 45		: 45
	: }		: }
	: }		: }
	: }		: }
	Figure 5: ASN.1-based Certificate: Example.		Figure 6: ASN.1-based Certificate: Example.
	To include the certificate shown in Figure 5 in a TLS/DTLS		To include the certificate shown in Figure 6 in a TLS/DTLS
	Certificate message it is prepended with a message header. This		Certificate message it is prepended with a message header. This
	Certificate message header in our example is 0b 00 02 36 00 02 33 00		Certificate message header in our example is 0b 00 02 36 00 02 33 00
	02 00 02 30, which indicates:		02 00 02 30, which indicates:
	Message Type: 0b -- 1 byte type field indicating a Certificate		Message Type: 0b -- 1 byte type field indicating a Certificate
	message		message
	Length: 00 02 36 -- 3 byte length field indicating a 566 bytes		Length: 00 02 36 -- 3 byte length field indicating a 566 bytes
	payload		payload
	skipping to change at page 16, line 4		skipping to change at page 16, line 9
	Length: 00 02 36 -- 3 byte length field indicating a 566 bytes		Length: 00 02 36 -- 3 byte length field indicating a 566 bytes
	payload		payload
	Certificates Length: 00 02 33 -- 3 byte length field indicating 563		Certificates Length: 00 02 33 -- 3 byte length field indicating 563
	bytes for the entire certificates_list structure, which may		bytes for the entire certificates_list structure, which may
	contain multiple certificates. In our example only one		contain multiple certificates. In our example only one
	certificate is included.		certificate is included.
	Certificate Length: 00 02 30 -- 3 byte length field indicating 560		Certificate Length: 00 02 30 -- 3 byte length field indicating 560
	bytes of the actual certificate following immediately afterwards.		bytes of the actual certificate following immediately afterwards.
	In our example, this is the certificate content with 30 82 02 ....		In our example, this is the certificate content with 30 82 02 ....
	9E 57 45 shown in Figure 6.		9E 57 45 shown in Figure 7.
	The hex encoding of the ASN.1 encoded certificate payload shown in		The hex encoding of the ASN.1 encoded certificate payload shown in
	Figure 5 leads to the following encoding.		Figure 6 leads to the following encoding.
	30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D		30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D
	30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B		30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B
	30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06		30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06
	03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C		03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C
	30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73		30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73
	6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D		6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D
	31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32		31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32
	33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B		33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B
	30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06		30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06
	skipping to change at page 16, line 47		skipping to change at page 17, line 41
	72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82		72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82
	09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86		09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86
	48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D		48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D
	7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C		7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C
	96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A		96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A
	C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00		C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00
	9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54		9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54
	2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42		2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42
	49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45		49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45
	Figure 6: Hex Encoding of the Example Certificate.		Figure 7: Hex Encoding of the Example Certificate.
	Applying the SHA-256 hash function to the Certificate message, which		Applying the SHA-256 hash function to the Certificate message, which
	is starts with 0b 00 02 and ends with 9E 57 45, produces		is starts with 0b 00 02 and ends with 9E 57 45, produces
	0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af.		0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af.
	Subsequently, this output is truncated to 32 bits, which leads to a		Subsequently, this output is truncated to 32 bits, which leads to a
	fingerpint of 0x086eefb4.		fingerpint of 0x086eefb4.
	Authors' Addresses		Authors' Addresses
	Stefan Santesson		Stefan Santesson
	3xA Security AB		3xA Security AB
	Scheelev. 17		Scheelev. 17
	Lund 223 70		Lund 223 70
	Sweden		Sweden
End of changes. 40 change blocks.
	65 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/