draft-ietf-ace-cwt-proof-of-possession-11.txt		rfc8747.txt
	ACE M. Jones		Internet Engineering Task Force (IETF) M. Jones
	Internet-Draft Microsoft		Request for Comments: 8747 Microsoft
	Intended status: Standards Track L. Seitz		Category: Standards Track L. Seitz
	Expires: May 3, 2020 RISE SICS		ISSN: 2070-1721 Combitech
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	S. Erdtman		S. Erdtman
	Spotify		Spotify
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	October 31, 2019		March 2020
	Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)		Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
	draft-ietf-ace-cwt-proof-of-possession-11
	Abstract		Abstract
	This specification describes how to declare in a CBOR Web Token (CWT)		This specification describes how to declare in a CBOR Web Token (CWT)
	(which is defined by RFC 8392) that the presenter of the CWT		(which is defined by RFC 8392) that the presenter of the CWT
	possesses a particular proof-of-possession key. Being able to prove		possesses a particular proof-of-possession key. Being able to prove
	possession of a key is also sometimes described as being the holder-		possession of a key is also sometimes described as being the holder-
	of-key. This specification provides equivalent functionality to		of-key. This specification provides equivalent functionality to
	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC		"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC
	7800) but using Concise Binary Object Representation (CBOR) and CWTs		7800) but using Concise Binary Object Representation (CBOR) and CWTs
	rather than JavaScript Object Notation (JSON) and JSON Web Tokens		rather than JavaScript Object Notation (JSON) and JSON Web Tokens
	(JWTs).		(JWTs).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on May 3, 2020.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8747.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology
	3. Representations for Proof-of-Possession Keys . . . . . . . . 3		3. Representations for Proof-of-Possession Keys
	3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4		3.1. Confirmation Claim
	3.2. Representation of an Asymmetric Proof-of-Possession Key . 5		3.2. Representation of an Asymmetric Proof-of-Possession Key
	3.3. Representation of an Encrypted Symmetric Proof-of-		3.3. Representation of an Encrypted Symmetric
	Possession Key . . . . . . . . . . . . . . . . . . . . . 6		Proof-of-Possession Key
	3.4. Representation of a Key ID for a Proof-of-Possession Key 7		3.4. Representation of a Key ID for a Proof-of-Possession Key
	3.5. Specifics Intentionally Not Specified . . . . . . . . . . 8		3.5. Specifics Intentionally Not Specified
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9		5. Privacy Considerations
	6. Operational Considerations . . . . . . . . . . . . . . . . . 9		6. Operational Considerations
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations
	7.1. CBOR Web Token Claims Registration . . . . . . . . . . . 11		7.1. CBOR Web Token Claims Registration
	7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11		7.1.1. Registry Contents
	7.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 11		7.2. CWT Confirmation Methods Registry
	7.2.1. Registration Template . . . . . . . . . . . . . . . . 11		7.2.1. Registration Template
	7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 12		7.2.2. Initial Registry Contents
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		8.2. Informative References
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14		Acknowledgements
	Document History . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This specification describes how a CBOR Web Token (CWT) [RFC8392] can		This specification describes how a CBOR Web Token (CWT) [RFC8392] can
	declare that the presenter of the CWT possesses a particular proof-		declare that the presenter of the CWT possesses a particular proof-
	of-possession (PoP) key. Proof of possession of a key is also		of-possession (PoP) key. Proof of possession of a key is also
	sometimes described as being the holder-of-key. This specification		sometimes described as being the holder-of-key. This specification
	provides equivalent functionality to "Proof-of-Possession Key		provides equivalent functionality to "Proof-of-Possession Key
	Semantics for JSON Web Tokens (JWTs)" [RFC7800] but using Concise		Semantics for JSON Web Tokens (JWTs)" [RFC7800] but using Concise
	Binary Object Representation (CBOR) [RFC7049] and CWTs [RFC8392]		Binary Object Representation (CBOR) [RFC7049] and CWTs [RFC8392]
	rather than JavaScript Object Notation (JSON) [RFC8259] and JSON Web		rather than JavaScript Object Notation (JSON) [RFC8259] and JSON Web
	Tokens (JWTs) [JWT].		Tokens (JWTs) [JWT].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This specification uses terms defined in the CBOR Web Token (CWT)		This specification uses terms defined in the CBOR Web Token (CWT)
	[RFC8392], CBOR Object Signing and Encryption (COSE) [RFC8152], and		[RFC8392], CBOR Object Signing and Encryption (COSE) [RFC8152], and
	Concise Binary Object Representation (CBOR) [RFC7049] specifications.		Concise Binary Object Representation (CBOR) [RFC7049] specifications.
	These terms are defined by this specification:		These terms are defined by this specification:
	Issuer		Issuer
	Party that creates the CWT and binds the claims about the subject		Party that creates the CWT and binds the claims about the subject
	skipping to change at page 4, line 9 ¶		skipping to change at line 143 ¶
	By including a "cnf" (confirmation) claim in a CWT, the issuer of the		By including a "cnf" (confirmation) claim in a CWT, the issuer of the
	CWT declares that the presenter possesses a particular key and that		CWT declares that the presenter possesses a particular key and that
	the recipient can cryptographically confirm that the presenter has		the recipient can cryptographically confirm that the presenter has
	possession of that key. The value of the "cnf" claim is a CBOR map		possession of that key. The value of the "cnf" claim is a CBOR map
	(which is defined in Section 2.1 of [RFC7049]) and the members of		(which is defined in Section 2.1 of [RFC7049]) and the members of
	that map identify the proof-of-possession key.		that map identify the proof-of-possession key.
	The presenter can be identified in one of several ways by the CWT,		The presenter can be identified in one of several ways by the CWT,
	depending upon the application requirements. For instance, some		depending upon the application requirements. For instance, some
	applications may use the CWT "sub" (subject) claim [RFC8392], to		applications may use the CWT "sub" (subject) claim [RFC8392] to
	identify the presenter. Other applications may use the "iss"		identify the presenter. Other applications may use the "iss"
	(issuer) claim [RFC8392] to identify the presenter. In some		(issuer) claim [RFC8392] to identify the presenter. In some
	applications, the subject identifier might be relative to the issuer		applications, the subject identifier might be relative to the issuer
	identified by the "iss" claim. The actual mechanism used is		identified by the "iss" claim. The actual mechanism used is
	dependent upon the application. The case in which the presenter is		dependent upon the application. The case in which the presenter is
	the subject of the CWT is analogous to Security Assertion Markup		the subject of the CWT is analogous to Security Assertion Markup
	Language (SAML) 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation		Language (SAML) 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation
	usage.		usage.
	3.1. Confirmation Claim		3.1. Confirmation Claim
	The "cnf" claim in the CWT is used to carry confirmation methods.		The "cnf" claim in the CWT is used to carry confirmation methods.
	Some of them use proof-of-possession keys while others do not. This		Some of them use proof-of-possession keys, while others do not. This
	design is analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]		design is analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]
	SubjectConfirmation element in which a number of different subject		SubjectConfirmation element in which a number of different subject
	confirmation methods can be included (including proof-of-possession		confirmation methods can be included (including proof-of-possession
	key information).		key information).
	The set of confirmation members that a CWT must contain to be		The set of confirmation members that a CWT must contain to be
	considered valid is context dependent and is outside the scope of		considered valid is context dependent and is outside the scope of
	this specification. Specific applications of CWTs will require		this specification. Specific applications of CWTs will require
	implementations to understand and process some confirmation members		implementations to understand and process some confirmation members
	in particular ways. However, in the absence of such requirements,		in particular ways. However, in the absence of such requirements,
	all confirmation members that are not understood by implementations		all confirmation members that are not understood by implementations
	MUST be ignored.		MUST be ignored.
	This specification establishes the IANA "CWT Confirmation Methods"		Section 7.2 establishes the IANA "CWT Confirmation Methods" registry
	registry for these members in Section 7.2 and registers the members		for CWT "cnf" member values and registers the members defined by this
	defined by this specification. Other specifications can register		specification. Other specifications can register other members used
	other members used for confirmation, including other members for		for confirmation, including other members for conveying proof-of-
	conveying proof-of-possession keys using different key		possession keys using different key representations.
	representations.
	The "cnf" claim value MUST represent only a single proof-of-		The "cnf" claim value MUST represent only a single proof-of-
	possession key. At most one of the "COSE_Key" and		possession key. At most one of the "COSE_Key" and
	"Encrypted_COSE_Key" confirmation values defined in Figure 1 may be		"Encrypted_COSE_Key" confirmation values defined in Table 1 may be
	present. Note that if an application needs to represent multiple		present. Note that if an application needs to represent multiple
	proof-of-possession keys in the same CWT, one way for it to achieve		proof-of-possession keys in the same CWT, one way for it to achieve
	this is to use other claim names, in addition to "cnf", to hold the		this is to use other claim names (in addition to "cnf") to hold the
	additional proof-of-possession key information. These claims could		additional proof-of-possession key information. These claims could
	use the same syntax and semantics as the "cnf" claim. Those claims		use the same syntax and semantics as the "cnf" claim. Those claims
	would be defined by applications or other specifications and could be		would be defined by applications or other specifications and could be
	registered in the IANA "CBOR Web Token Claims" registry		registered in the IANA "CBOR Web Token (CWT) Claims" registry
	[IANA.CWT.Claims].		[IANA.CWT.Claims].
	/--------------------+-----+-------------------------------\		+--------------------+-----+-------------------------------+
	| Name | Key | Value type |		| Name | Key | Value type |
	|--------------------+-----+-------------------------------|		+====================+=====+===============================+
	| COSE_Key | 1 | COSE_Key |		| COSE_Key | 1 | COSE_Key |
	| Encrypted_COSE_Key | 2 | COSE_Encrypt or COSE_Encrypt0 |		+--------------------+-----+-------------------------------+
	| kid | 3 | binary string |		| Encrypted_COSE_Key | 2 | COSE_Encrypt or COSE_Encrypt0 |
	\--------------------+-----+-------------------------------/		+--------------------+-----+-------------------------------+
			| kid | 3 | binary string |
			+--------------------+-----+-------------------------------+
	Figure 1: Summary of the cnf names, keys, and value types		Table 1: Summary of the "cnf" Names, Keys, and Value Types
	3.2. Representation of an Asymmetric Proof-of-Possession Key		3.2. Representation of an Asymmetric Proof-of-Possession Key
	When the key held by the presenter is an asymmetric private key, the		When the key held by the presenter is an asymmetric private key, the
	"COSE_Key" member is a COSE_Key [RFC8152] representing the		"COSE_Key" member is a COSE_Key [RFC8152] representing the
	corresponding asymmetric public key. The following example		corresponding asymmetric public key. The following example
	demonstrates such a declaration in the CWT Claims Set of a CWT:		demonstrates such a declaration in the CWT Claims Set of a CWT:
	{		{
	/iss/ 1 : "coaps://server.example.com",		/iss/ 1 : "coaps://server.example.com",
	/aud/ 3 : "coaps://client.example.org",		/aud/ 3 : "coaps://client.example.org",
	/exp/ 4 : 1879067471,		/exp/ 4 : 1879067471,
	/cnf/ 8 :{		/cnf/ 8 :{
	/COSE_Key/ 1 :{		/COSE_Key/ 1 :{
	/kty/ 1 : /EC2/ 2,		/kty/ 1 : /EC2/ 2,
	/crv/ -1 : /P-256/ 1,		/crv/ -1 : /P-256/ 1,
	/x/ -2 : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa27c9		/x/ -2 : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa27c9
	e354089bbe13',		e354089bbe13',
	/y/ -3 : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020731e		/y/ -3 : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020731e
	79a3b4e47120'		79a3b4e47120'
	}		}
	}		}
	}		}
	The COSE_Key MUST contain the required key members for a COSE_Key of		The COSE_Key MUST contain the required key members for a COSE_Key of
	that key type and MAY contain other COSE_Key members, including the		that key type and MAY contain other COSE_Key members, including the
	"kid" (Key ID) member.		"kid" (Key ID) member.
	The "COSE_Key" member MAY also be used for a COSE_Key representing a		The "COSE_Key" member MAY also be used for a COSE_Key representing a
	symmetric key, provided that the CWT is encrypted so that the key is		symmetric key, provided that the CWT is encrypted so that the key is
	not revealed to unintended parties. The means of encrypting a CWT is		not revealed to unintended parties. The means of encrypting a CWT is
	explained in [RFC8392]. If the CWT is not encrypted, the symmetric		explained in [RFC8392]. If the CWT is not encrypted, the symmetric
	key MUST be encrypted as described in Section 3.3. This procedure is		key MUST be encrypted as described in Section 3.3. This procedure is
	equivalent to the one defined in section 3.3 of [RFC7800].		equivalent to the one defined in Section 3.3 of [RFC7800].
	3.3. Representation of an Encrypted Symmetric Proof-of-Possession Key		3.3. Representation of an Encrypted Symmetric Proof-of-Possession Key
	When the key held by the presenter is a symmetric key, the		When the key held by the presenter is a symmetric key, the
	"Encrypted_COSE_Key" member is an encrypted COSE_Key [RFC8152]		"Encrypted_COSE_Key" member is an encrypted COSE_Key [RFC8152]
	representing the symmetric key encrypted to a key known to the		representing the symmetric key encrypted to a key known to the
	recipient using COSE_Encrypt or COSE_Encrypt0.		recipient using COSE_Encrypt or COSE_Encrypt0.
	The following example illustrates a symmetric key that could		The following example illustrates a symmetric key that could
	subsequently be encrypted for use in the "Encrypted_COSE_Key" member:		subsequently be encrypted for use in the "Encrypted_COSE_Key" member:
	{		{
	/kty/ 1 : /Symmetric/ 4,		/kty/ 1 : /Symmetric/ 4,
	/alg/ 3 : /HMAC 256-256/ 5,		/alg/ 3 : /HMAC 256-256/ 5,
	/k/ -1 : h'6684523ab17337f173500e5728c628547cb37df		/k/ -1 : h'6684523ab17337f173500e5728c628547cb37df
	e68449c65f885d1b73b49eae1'		e68449c65f885d1b73b49eae1'
	}		}
	The COSE_Key representation is used as the plaintext when encrypting		The COSE_Key representation is used as the plaintext when encrypting
	the key.		the key.
	The following example CWT Claims Set of a CWT illustrates the use of		The following example CWT Claims Set of a CWT illustrates the use of
	an encrypted symmetric key as the "Encrypted_COSE_Key" member value:		an encrypted symmetric key as the "Encrypted_COSE_Key" member value:
	{		{
	/iss/ 1 : "coaps://server.example.com",		/iss/ 1 : "coaps://server.example.com",
	/sub/ 2 : "24400320",		/sub/ 2 : "24400320",
	/aud/ 3: "s6BhdRkqt3",		/aud/ 3: "s6BhdRkqt3",
	/exp/ 4 : 1311281970,		/exp/ 4 : 1311281970,
	/iat/ 5 : 1311280970,		/iat/ 5 : 1311280970,
	/cnf/ 8 : {		/cnf/ 8 : {
	/Encrypted_COSE_Key/ 2 : [		/Encrypted_COSE_Key/ 2 : [
	/protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,		/protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,
	/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},		/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},
	/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E		/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E
	A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'		A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'
	]		]
	}		}
	}		}
	The example above was generated with the key:		The example above was generated with the key:
	h'6162630405060708090a0b0c0d0e0f10'		h'6162630405060708090a0b0c0d0e0f10'
	3.4. Representation of a Key ID for a Proof-of-Possession Key		3.4. Representation of a Key ID for a Proof-of-Possession Key
	The proof-of-possession key can also be identified using a Key ID		The proof-of-possession key can also be identified using a Key ID
	instead of communicating the actual key, provided the recipient is		instead of communicating the actual key, provided the recipient is
	able to obtain the identified key using the Key ID. In this case,		able to obtain the identified key using the Key ID. In this case,
	the issuer of a CWT declares that the presenter possesses a		the issuer of a CWT declares that the presenter possesses a
	particular key and that the recipient can cryptographically confirm		particular key and that the recipient can cryptographically confirm
	proof of possession of the key by the presenter by including a "cnf"		the presenter's proof of possession of the key by including a "cnf"
	claim in the CWT whose value is a CBOR map with the CBOR map		claim in the CWT whose value is a CBOR map containing a "kid" member
	containing a "kid" member identifying the key.		identifying the key.
	The following example demonstrates such a declaration in the CWT		The following example demonstrates such a declaration in the CWT
	Claims Set of a CWT:		Claims Set of a CWT:
	{		{
	/iss/ 1 : "coaps://as.example.com",		/iss/ 1 : "coaps://as.example.com",
	/aud/ 3 : "coaps://resource.example.org",		/aud/ 3 : "coaps://resource.example.org",
	/exp/ 4 : 1361398824,		/exp/ 4 : 1361398824,
	/cnf/ 8 : {		/cnf/ 8 : {
	/kid/ 3 : h'dfd1aa976d8d4575a0fe34b96de2bfad'		/kid/ 3 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
	}
	}		}
			}
	The content of the "kid" value is application specific. For		The content of the "kid" value is application specific. For
	instance, some applications may choose to use a cryptographic hash of		instance, some applications may choose to use a cryptographic hash of
	the public key value as the "kid" value.		the public key value as the "kid" value.
	Note that the use of a Key ID to identify a proof-of-possession key		Note that the use of a Key ID to identify a proof-of-possession key
	needs to be carefully circumscribed, as described below and in		needs to be carefully circumscribed, as described below and in
	Section 6. In cases where the Key ID is not a cryptographic value		Section 6. In cases where the Key ID is not a cryptographic value
	derived from the key or where not all of the parties involved are		derived from the key or where not all of the parties involved are
	validating the cryptographic derivation, implementers should expect		validating the cryptographic derivation, implementers should expect
	collisions, where different keys are assigned the same Key ID.		collisions where different keys are assigned the same Key ID.
	Recipients of a CWT with a PoP key linked through only a Key ID		Recipients of a CWT with a PoP key linked through only a Key ID
	should be prepared to handle such situations.		should be prepared to handle such situations.
	In the world of constrained Internet of Things (IoT) devices, there		In the world of constrained Internet of Things (IoT) devices, there
	is frequently a restriction on the size of Key IDs, either because of		is frequently a restriction on the size of Key IDs, either because of
	table constraints or a desire to keep message sizes small.		table constraints or a desire to keep message sizes small.
	Note that the value of a Key ID for a specific key is not necessarily		Note that the value of a Key ID for a specific key is not necessarily
	the same for different parties. When sending a COSE encrypted		the same for different parties. When sending a COSE encrypted
	message with a shared key, the Key ID may be different on both sides		message with a shared key, the Key ID may be different on both sides
	skipping to change at page 8, line 24 ¶		skipping to change at line 342 ¶
	The means of communicating the nonce and the nature of its contents		The means of communicating the nonce and the nature of its contents
	are intentionally not described in this specification, as different		are intentionally not described in this specification, as different
	protocols will communicate this information in different ways.		protocols will communicate this information in different ways.
	Likewise, the means of communicating the signed nonce is also not		Likewise, the means of communicating the signed nonce is also not
	specified, as this is also protocol specific.		specified, as this is also protocol specific.
	Note that other means of proving possession of the key exist, which		Note that other means of proving possession of the key exist, which
	could be used in conjunction with a CWT's confirmation key.		could be used in conjunction with a CWT's confirmation key.
	Applications making use of such alternate means are encouraged to		Applications making use of such alternate means are encouraged to
	register them in the IANA "CWT Confirmation Methods" registry		register them in the IANA "CBOR Web Token (CWT) Confirmation Methods"
	established in Section 7.2.		registry established in Section 7.2.
	4. Security Considerations		4. Security Considerations
	All the security considerations that are discussed in [RFC8392] also		All the security considerations that are discussed in [RFC8392] also
	apply here. In addition, proof of possession introduces its own		apply here. In addition, proof of possession introduces its own
	unique security issues. Possessing a key is only valuable if it is		unique security issues. Possessing a key is only valuable if it is
	kept secret. Appropriate means must be used to ensure that		kept secret. Appropriate means must be used to ensure that
	unintended parties do not learn private key or symmetric key values.		unintended parties do not learn private key or symmetric key values.
	Applications utilizing proof of possession SHOULD also utilize		Applications utilizing proof of possession SHOULD also utilize
	audience restriction, as described in Section 3.1.3 of [RFC8392], as		audience restriction, as described in Section 3.1.3 of [RFC8392],
	it provides additional protections. Audience restriction can be used		because it provides additional protections. Audience restriction can
	by recipients to reject messages intended for different recipients.		be used by recipients to reject messages intended for different
	(Of course, applications not using proof of possession can also		recipients. (Of course, applications not using proof of possession
	benefit from using audience restriction to reject messages intended		can also benefit from using audience restriction to reject messages
	for different recipients.)		intended for different recipients.)
	CBOR Web Tokens with proof-of-possession keys are used in context of		CBOR Web Tokens with proof-of-possession keys are used in context of
	an architecture, such as the ACE OAuth Framework		an architecture, such as the ACE OAuth Framework [ACE-OAUTH], in
	[I-D.ietf-ace-oauth-authz], in which protocols are used by a		which protocols are used by a presenter to request these tokens and
	presenter to request these tokens and to subsequently use them with		to subsequently use them with recipients. Proof of possession only
	recipients. Proof of possession only provides the intended security		provides the intended security gains when the proof is known to be
	gains when the proof is known to be current and not subject to replay		current and not subject to replay attacks; security protocols using
	attacks; security protocols using mechanisms such as nonces and		mechanisms such as nonces and timestamps can be used to avoid the
	timestamps can be used to avoid the risk of replay when performing		risk of replay when performing proof of possession for a token. Note
	proof of possession for a token. Note that a discussion of the		that a discussion of the architecture or specific protocols that CWTs
	architecture or specific protocols that CWT proof-of-possession		with proof-of-possession keys are used with is beyond the scope of
	tokens are used with is beyond the scope of this specification.		this specification.
	As is the case with other information included in a CWT, it is		As is the case with other information included in a CWT, it is
	necessary to apply data origin authentication and integrity		necessary to apply data origin authentication and integrity
	protection (via a keyed message digest or a digital signature). Data		protection (via a keyed message digest or a digital signature). Data
	origin authentication ensures that the recipient of the CWT learns		origin authentication ensures that the recipient of the CWT learns
	about the entity that created the CWT since this will be important		about the entity that created the CWT, since this will be important
	for any policy decisions. Integrity protection prevents an adversary		for any policy decisions. Integrity protection prevents an adversary
	from changing any elements conveyed within the CWT payload. Special		from changing any elements conveyed within the CWT payload. Special
	care has to be applied when carrying symmetric keys inside the CWT		care has to be applied when carrying symmetric keys inside the CWT
	since those not only require integrity protection but also		since those not only require integrity protection but also
	confidentiality protection.		confidentiality protection.
	As described in Section 6 (Key Identification) and Appendix D (Notes		As described in Section 6 (Key Identification) and Appendix D (Notes
	on Key Selection) of [JWS], it is important to make explicit trust		on Key Selection) of [JWS], it is important to make explicit trust
	decisions about the keys. Proof-of-possession signatures made with		decisions about the keys. Proof-of-possession signatures made with
	keys not meeting the application's trust criteria MUST NOT be relied		keys not meeting the application's trust criteria MUST NOT be relied
	skipping to change at page 9, line 51 ¶		skipping to change at line 417 ¶
	recipient about the claims being used (which is also true of CWTs in		recipient about the claims being used (which is also true of CWTs in
	general).		general).
	When an issuer creates a CWT containing a Key ID claim, it needs to		When an issuer creates a CWT containing a Key ID claim, it needs to
	make sure that it does not issue another CWT with different claims		make sure that it does not issue another CWT with different claims
	containing the same Key ID within the lifetime of the CWTs, unless		containing the same Key ID within the lifetime of the CWTs, unless
	intentionally desired. Failure to do so may allow one party to		intentionally desired. Failure to do so may allow one party to
	impersonate another party, with the potential to gain additional		impersonate another party, with the potential to gain additional
	privileges. A case where such reuse of a Key ID would be intentional		privileges. A case where such reuse of a Key ID would be intentional
	is when a presenter obtains a CWT with different claims (e.g.,		is when a presenter obtains a CWT with different claims (e.g.,
	extended scope) for the same recipient, but wants to continue using		extended scope) for the same recipient but wants to continue using an
	an existing security association (e.g., a DTLS session) bound to the		existing security association (e.g., a DTLS session) bound to the key
	key identified by the Key ID. Likewise, if PoP keys are used for		identified by the Key ID. Likewise, if PoP keys are used for
	multiple different kinds of CWTs in an application and the PoP keys		multiple different kinds of CWTs in an application and the PoP keys
	are identified by Key IDs, care must be taken to keep the keys for		are identified by Key IDs, care must be taken to keep the keys for
	the different kinds of CWTs segregated so that an attacker cannot		the different kinds of CWTs segregated so that an attacker cannot
	cause the wrong PoP key to be used by using a valid Key ID for the		cause the wrong PoP key to be used by using a valid Key ID for the
	wrong kind of CWT. Using an audience restriction for the CWT would		wrong kind of CWT. Using an audience restriction for the CWT would
	be one strategy to mitigate this risk.		be one strategy to mitigate this risk.
	7. IANA Considerations		7. IANA Considerations
	The following registration procedure is used for all the registries		The following registration procedure is used for all the registries
	established by this specification.		established by this specification.
	Values are registered on a Specification Required [RFC8126] basis		Values are registered on a Specification Required [RFC8126] basis
	after a three-week review period on the cwt-reg-review@ietf.org		after a three-week review period on the <cwt-reg-review@ietf.org>
	mailing list, on the advice of one or more Designated Experts.		mailing list, on the advice of one or more designated experts.
	However, to allow for the allocation of values prior to publication,		However, to allow for the allocation of values prior to publication,
	the Designated Experts may approve registration once they are		the designated experts may approve registration once they are
	satisfied that such a specification will be published. [[ Note to		satisfied that such a specification will be published.
	the RFC Editor: The name of the mailing list should be determined in
	consultation with the IESG and IANA. Suggested name: cwt-reg-
	review@ietf.org. ]]
	Registration requests sent to the mailing list for review should use		Registration requests sent to the mailing list for review should use
	an appropriate subject (e.g., "Request to Register CWT Confirmation		an appropriate subject (e.g., "Request to Register CWT Confirmation
	Method: example"). Registration requests that are undetermined for a		Method: example"). Registration requests that are undetermined for a
	period longer than 21 days can be brought directly to IANA's		period longer than 21 days can be brought directly to IANA's
	attention (using the iana@iana.org mailing list) for resolution.		attention (using the iana@iana.org mailing list) for resolution.
	Designated Experts should determine whether a registration request		Designated experts should determine whether a registration request
	contains enough information for the registry to be populated with the		contains enough information for the registry to be populated with the
	new values and whether the proposed new functionality already exists.		new values and whether the proposed new functionality already exists.
	In the case of an incomplete registration or an attempt to register		In the case of an incomplete registration or an attempt to register
	already existing functionality, the Designated Experts should ask for		already existing functionality, the designated experts should ask for
	corrections or reject the registration.		corrections or reject the registration.
	It is suggested that multiple Designated Experts be appointed who are		It is suggested that multiple designated experts be appointed who are
	able to represent the perspectives of different applications using		able to represent the perspectives of different applications using
	this specification in order to enable broadly informed review of		this specification in order to enable broadly informed review of
	registration decisions. In cases where a registration decision could		registration decisions. In cases where a registration decision could
	be perceived as creating a conflict of interest for a particular		be perceived as creating a conflict of interest for a particular
	Expert, that Expert should defer to the judgment of the other		expert, that expert should defer to the judgment of the other
	Experts.		experts.
	7.1. CBOR Web Token Claims Registration		7.1. CBOR Web Token Claims Registration
	This specification registers the "cnf" claim in the IANA "CBOR Web		This specification registers the "cnf" claim in the IANA "CBOR Web
	Token Claims" registry [IANA.CWT.Claims] established by [RFC8392].		Token (CWT) Claims" registry [IANA.CWT.Claims], established by
			[RFC8392].
	7.1.1. Registry Contents		7.1.1. Registry Contents
	o Claim Name: "cnf"		* Claim Name: "cnf"
	o Claim Description: Confirmation
	o JWT Claim Name: "cnf"		* Claim Description: Confirmation
	o Claim Key: TBD (maybe 8)
	o Claim Value Type(s): map		* JWT Claim Name: "cnf"
	o Change Controller: IESG
	o Specification Document(s): Section 3.1 of [[ this document ]]		* Claim Key: 8
			* Claim Value Type(s): map
			* Change Controller: IESG
			* Specification Document(s): Section 3.1 of RFC 8747
	7.2. CWT Confirmation Methods Registry		7.2. CWT Confirmation Methods Registry
	This specification establishes the IANA "CWT Confirmation Methods"		This specification establishes the IANA "CWT Confirmation Methods"
	registry for CWT "cnf" member values. The registry records the		registry for CWT "cnf" member values. The registry records the
	confirmation method member and a reference to the specification that		confirmation method member and a reference to the specification that
	defines it.		defines it.
	7.2.1. Registration Template		7.2.1. Registration Template
	Confirmation Method Name:		Confirmation Method Name:
	The human-readable name requested (e.g., "kid").		The human-readable name requested (e.g., "kid").
	Confirmation Method Description:		Confirmation Method Description:
	Brief description of the confirmation method (e.g., "Key		Brief description of the confirmation method (e.g., "Key
	Identifier").		Identifier").
	JWT Confirmation Method Name:		JWT Confirmation Method Name:
	Claim Name of the equivalent JWT confirmation method value, as		Claim Name of the equivalent JWT confirmation method value, as
	registered in [IANA.JWT.Claims]. CWT claims should normally have		registered in the "JSON Web Token Claims" subregistry in the "JSON
	a corresponding JWT claim. If a corresponding JWT claim would not		Web Token (JWT)" registry [IANA.JWT]. CWT claims should normally
	make sense, the Designated Experts can choose to accept		have a corresponding JWT claim. If a corresponding JWT claim
			would not make sense, the designated experts can choose to accept
	registrations for which the JWT Claim Name is listed as "N/A".		registrations for which the JWT Claim Name is listed as "N/A".
	Confirmation Key:		Confirmation Key:
	CBOR map key value for the confirmation method.		CBOR map key value for the confirmation method.
	Confirmation Value Type(s):		Confirmation Value Type(s):
	CBOR types that can be used for the confirmation method value.		CBOR types that can be used for the confirmation method value.
	Change Controller:		Change Controller:
	For Standards Track RFCs, list the "IESG". For others, give the		For Standards Track RFCs, list the "IESG". For others, give the
	name of the responsible party.		name of the responsible party.
	Specification Document(s):		Specification Document(s):
	Reference to the document or documents that specify the parameter,		Reference to the document or documents that specify the parameter,
	preferably including URIs that can be used to retrieve copies of		preferably including URIs that can be used to retrieve copies of
	the documents. An indication of the relevant sections may also be		the documents. An indication of the relevant sections may also be
	included but is not required. Note that the Designated Experts		included but is not required. Note that the designated experts
	and IANA must be able to obtain copies of the specification		and IANA must be able to obtain copies of the specification
	document(s) to perform their work.		document(s) to perform their work.
	7.2.2. Initial Registry Contents		7.2.2. Initial Registry Contents
	o Confirmation Method Name: "COSE_Key"		* Confirmation Method Name: "COSE_Key"
	o Confirmation Method Description: COSE_Key Representing Public Key		* Confirmation Method Description: COSE_Key Representing Public Key
	o JWT Confirmation Method Name: "jwk"		* JWT Confirmation Method Name: "jwk"
	o Confirmation Key: 1		* Confirmation Key: 1
	o Confirmation Value Type(s): COSE_Key structure		* Confirmation Value Type(s): COSE_Key structure
	o Change Controller: IESG		* Change Controller: IESG
	o Specification Document(s): Section 3.2 of [[ this document ]]		* Specification Document(s): Section 3.2 of RFC 8747
	o Confirmation Method Name: "Encrypted_COSE_Key"		* Confirmation Method Name: "Encrypted_COSE_Key"
	o Confirmation Method Description: Encrypted COSE_Key		* Confirmation Method Description: Encrypted COSE_Key
	o JWT Confirmation Method Name: "jwe"		* JWT Confirmation Method Name: "jwe"
	o Confirmation Key: 2		* Confirmation Key: 2
	o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0		* Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
	structure (with an optional corresponding COSE_Encrypt or		structure (with an optional corresponding COSE_Encrypt or
	COSE_Encrypt0 tag)		COSE_Encrypt0 tag)
	o Change Controller: IESG		* Change Controller: IESG
	o Specification Document(s): Section 3.3 of [[ this document ]]		* Specification Document(s): Section 3.3 of RFC 8747
	o Confirmation Method Name: "kid"		* Confirmation Method Name: "kid"
	o Confirmation Method Description: Key Identifier		* Confirmation Method Description: Key Identifier
	o JWT Confirmation Method Name: "kid"		* JWT Confirmation Method Name: "kid"
	o Confirmation Key: 3		* Confirmation Key: 3
	o Confirmation Value Type(s): binary string		* Confirmation Value Type(s): binary string
	o Change Controller: IESG		* Change Controller: IESG
	o Specification Document(s): Section 3.4 of [[ this document ]]		* Specification Document(s): Section 3.4 of RFC 8747
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[IANA.CWT.Claims]		[IANA.CWT.Claims]
	IANA, "CBOR Web Token Claims",		IANA, "CBOR Web Token Claims",
	<http://www.iana.org/assignments/cwt>.		<https://www.iana.org/assignments/cwt>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	skipping to change at page 13, line 28 ¶		skipping to change at line 588 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,		"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/info/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-ace-oauth-authz]		[ACE-OAUTH]
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) using the OAuth 2.0		Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-21		Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
	(work in progress), February 2019.		draft-ietf-ace-oauth-authz-21, 14 February 2019,
			<https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
			21>.
	[IANA.JWT.Claims]		[IANA.JWT] IANA, "JSON Web Token (JWT)",
	IANA, "JSON Web Token Claims",		<https://www.iana.org/assignments/jwt>.
	<http://www.iana.org/assignments/jwt>.
	[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May		Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
	2015, <http://www.rfc-editor.org/info/rfc7515>.		2015, <https://www.rfc-editor.org/info/rfc7515>.
	[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<http://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[OASIS.saml-core-2.0-os]		[OASIS.saml-core-2.0-os]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	"Assertions and Protocol for the OASIS Security Assertion		"Assertions and Protocol for the OASIS Security Assertion
	Markup Language (SAML) V2.0", OASIS Standard saml-core-		Markup Language (SAML) V2.0", OASIS Standard saml-core-
	2.0-os, March 2005,		2.0-os, March 2005, <https://docs.oasis-
	<http://docs.oasis-open.org/security/saml/v2.0/>.		open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
	[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)",		Possession Key Semantics for JSON Web Tokens (JWTs)",
	RFC 7800, DOI 10.17487/RFC7800, April 2016,		RFC 7800, DOI 10.17487/RFC7800, April 2016,
	<https://www.rfc-editor.org/info/rfc7800>.		<https://www.rfc-editor.org/info/rfc7800>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,		DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	skipping to change at page 14, line 25 ¶		skipping to change at line 635 ¶
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	Acknowledgements		Acknowledgements
	Thanks to the following people for their reviews of the		Thanks to the following people for their reviews of the
	specification: Roman Danyliw, Christer Holmberg, Benjamin Kaduk,		specification: Roman Danyliw, Christer Holmberg, Benjamin Kaduk,
	Mirja Kuehlewind, Yoav Nir, Michael Richardson, Adam Roach, Eric		Mirja Kühlewind, Yoav Nir, Michael Richardson, Adam Roach, Éric
	Vyncke, and Jim Schaad.		Vyncke, and Jim Schaad.
	Ludwig Seitz and Goeran Selander worked on this document as part of		Ludwig Seitz and Göran Selander worked on this document as part of
	the CelticPlus projects CyberWI and CRITISEC, with funding from		the CelticPlus projects CyberWI and CRITISEC, with funding from
	Vinnova.		Vinnova.
	Document History
	[[ to be removed by the RFC Editor before publication as an RFC ]]
	-11
	o Addressed remaining IESG review comment by Mirja Kuehlewind.
	-10
	o Addressed IESG review comments by Adam Roach and Eric Vyncke.
	-09
	o Addressed Gen-ART review comments by Christer Holmberg and SecDir
	review comments by Yoav Nir.
	-08
	o Addressed remaining Area Director review comments by Benjamin
	Kaduk.
	-07
	o Addressed Area Director review by Benjamin Kaduk.
	-06
	o Corrected nits identified by Roman Danyliw.
	-05
	o Added text suggested by Jim Schaad describing considerations when
	using the Key ID confirmation method.
	-04
	o Addressed additional WGLC comments by Jim Schaad and Roman
	Danyliw.
	-03
	o Addressed review comments by Jim Schaad, see https://www.ietf.org/
	mail-archive/web/ace/current/msg02798.html
	o Removed unnecessary sentence in the introduction regarding the use
	any strings that could be case-sensitive.
	o Clarified the terms Presenter and Recipient.
	o Clarified text about the confirmation claim.
	-02
	o Changed "typically" to "often" when describing ways of performing
	proof of possession.
	o Changed b64 to hex encoding in an example.
	o Changed to using the RFC 8174 boilerplate instead of the RFC 2119
	boilerplate.
	-01
	o Now uses CBOR diagnostic notation for the examples.
	o Added a table summarizing the "cnf" names, keys, and value types.
	o Addressed some of Jim Schaad's feedback on -00.
	-00
	o Created the initial working group draft from draft-jones-ace-cwt-
	proof-of-possession-01.
	Authors' Addresses		Authors' Addresses
	Michael B. Jones		Michael B. Jones
	Microsoft		Microsoft
	Email: mbj@microsoft.com		Email: mbj@microsoft.com
	URI: http://self-issued.info/		URI: https://self-issued.info/
	Ludwig Seitz		Ludwig Seitz
	RISE SICS		Combitech
	Scheelevaegen 17		Djaeknegatan 31
	Lund 223 70		SE-211 35 Malmö
	Sweden		Sweden
	Email: ludwig@ri.se		Email: ludwig.seitz@combitech.se
	Goeran Selander		Göran Selander
	Ericsson AB		Ericsson AB
	Faeroegatan 6		SE-164 80 Kista
	Kista 164 80
	Sweden		Sweden
	Email: goran.selander@ericsson.com		Email: goran.selander@ericsson.com
	Samuel Erdtman		Samuel Erdtman
	Spotify		Spotify
	Email: erdtman@spotify.com		Email: erdtman@spotify.com
	Hannes Tschofenig		Hannes Tschofenig
	Arm Ltd.		Arm Ltd.
	Hall in Tirol 6060		6060 Hall in Tirol
	Austria		Austria
	Email: Hannes.Tschofenig@arm.com		Email: Hannes.Tschofenig@arm.com
End of changes. 62 change blocks.
	273 lines changed or deleted		199 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/