< draft-ietf-ace-cwt-proof-of-possession-04.txt		draft-ietf-ace-cwt-proof-of-possession-05.txt >
	ACE M. Jones		ACE M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track L. Seitz		Intended status: Standards Track L. Seitz
	Expires: May 10, 2019 RISE SICS		Expires: May 13, 2019 RISE SICS
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	S. Erdtman		S. Erdtman
	Spotify		Spotify
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	November 6, 2018		November 9, 2018
	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-04		draft-ietf-ace-cwt-proof-of-possession-05
	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)
	that the presenter of the CWT possesses a particular proof-of-		that the presenter of the CWT possesses a particular proof-of-
	possession key. Being able to prove possession of a key is also		possession key. Being able to prove 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)" (RFC 7800), but using CBOR and		Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and
	CWTs rather than JSON and JWTs.		CWTs rather than JSON and JWTs.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 May 10, 2019.		This Internet-Draft will expire on May 13, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Representations for Proof-of-Possession Keys . . . . . . . . 3		3. Representations for Proof-of-Possession Keys . . . . . . . . 3
	3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4		3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4
	3.2. Representation of an Asymmetric Proof-of-Possession Key . 5		3.2. Representation of an Asymmetric Proof-of-Possession Key . 5
	3.3. Representation of an Encrypted Symmetric Proof-of-		3.3. Representation of an Encrypted Symmetric Proof-of-
	Possession Key . . . . . . . . . . . . . . . . . . . . . 5		Possession Key . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Representation of a Key ID for a Proof-of-Possession Key 6		3.4. Representation of a Key ID for a Proof-of-Possession Key 6
	3.5. Specifics Intentionally Not Specified . . . . . . . . . . 7		3.5. Specifics Intentionally Not Specified . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
	6. Operational Considerations . . . . . . . . . . . . . . . . . 8		6. Operational Considerations . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7.1. CBOR Web Token Claims Registration . . . . . . . . . . . 10		7.1. CBOR Web Token Claims Registration . . . . . . . . . . . 11
	7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 10		7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11
	7.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 10		7.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 11
	7.2.1. Registration Template . . . . . . . . . . . . . . . . 10		7.2.1. Registration Template . . . . . . . . . . . . . . . . 11
	7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 11		7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
	Document History . . . . . . . . . . . . . . . . . . . . . . . . 13		Document History . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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 CBOR		Semantics for JSON Web Tokens (JWTs)" [RFC7800], but using CBOR
	[RFC7049] and CWTs [RFC8392] rather than JSON [RFC7159] and JWTs		[RFC7049] and CWTs [RFC8392] rather than JSON [RFC7159] and JWTs
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 18 ¶
	/exp/ 4 : 1361398824,		/exp/ 4 : 1361398824,
	/cnf/ 8 : {		/cnf/ 8 : {
	/kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'		/kid/ 2 : 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-possesion key
			needs to be carefully circumscribed, as described below and in
			Section 6. Where the Key ID is not a cryptographic value derived
			from the key or where all of the parties involved are not validating
			the cryptographic derivation, it is possible to get into situations
			where the same Key ID is being used for multiple keys. The
			implication of this is that a recipient may have multiple keys known
			to it that have the same Key ID, and thus it might not know which
			proof-of-possession key is associated with the CWT.
			In the world of constrained Internet of Things (IoT) devices, there
			is frequently a restriction on the size of Key IDs, either because of
			table constraints or a desire to keep message sizes small. These
			restrictions are going to protocol dependent. For example, DTLS can
			use a Key ID of any size. However, if the key is being used with
			COSE encrypted message, then the length of the key needs to be
			minimized and may have a limit as small as one byte.
			Note that the value of a Key ID is not always the same for different
			parties. When sending a COSE encrypted message with a shared key,
			the Key ID may be different on both sides of the conversation, with
			the appropriate one being included in the message based on the
			recipient of the message.
			For symmetric keys, the Key ID is normally going to be generated by
			the CWT issuer. This means that enforcing a rule that Key ID values
			only match if CWTs have the same issuer works for matching Key IDs
			between CWTs. In this case, the issuer can ensure that there are no
			collisions between currently active symmetric keys for all CWTs that
			it has issued. This allows for a recipient to use the pair of issuer
			and Key ID for matching keys.
			For asymmetric keys, the Key ID value is normally going to be
			generated by the CWT recipient, thus the possibility of collisions is
			greater. For instance, recipients might start by assigning a Key ID
			of 0, given that Key IDs are frequently only needed to be unique and
			meaningful to the recipient. This problem can be addressed in a
			couple of different ways, depending on how the Key ID value is going
			to be used:
			o The issuer can assign a new unique Key ID the first time it sees
			the key. Depending on the protocol being used, the new value may
			then need to be transported to the presenter by the protocol used
			to issue CWTs. In this case, the rule of requiring that the
			issuer, Key ID pair be used for matching works.
			o The issuer can use a different confirmation method if a collision
			might be unavoidable.
			o A recipient can decide not to use a CWT based on a created Key ID
			if it does not fit the recipient's requirements.
			o If an issuer is going to use the Key ID confirmation method and is
			not going to guarantee that serial number uniqueness is going to
			be preserved, the recipient needs to have that information
			configured into it so that appropriate actions can be taken.
	3.5. Specifics Intentionally Not Specified		3.5. Specifics Intentionally Not Specified
	Proof of possession is often demonstrated by having the presenter		Proof of possession is often demonstrated by having the presenter
	sign a value determined by the recipient using the key possessed by		sign a value determined by the recipient using the key possessed by
	the presenter. This value is sometimes called a "nonce" or a		the presenter. This value is sometimes called a "nonce" or a
	"challenge".		"challenge".
	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.
	skipping to change at page 13, line 26 ¶		skipping to change at page 14, line 41 ¶
	Thanks to the following people for their reviews of the		Thanks to the following people for their reviews of the
	specification: Roman Danyliw, Michael Richardson, and Jim Schaad.		specification: Roman Danyliw, Michael Richardson, and Jim Schaad.
	Ludwig Seitz and Goeran Selander worked on this document as part of		Ludwig Seitz and Goeran Selander worked on this document as part of
	the CelticPlus project CyberWI, with funding from Vinnova.		the CelticPlus project CyberWI, with funding from Vinnova.
	Document History		Document History
	[[ to be removed by the RFC Editor before publication as an RFC ]]		[[ to be removed by the RFC Editor before publication as an RFC ]]
			-05
			o Added text suggested by Jim Schaad describing considerations when
			using the Key ID confirmation method.
	-04		-04
	o Addressed additional WGLC comments by Jim Schaad and Roman		o Addressed additional WGLC comments by Jim Schaad and Roman
	Danyliw.		Danyliw.
	-03		-03
	o Addressed review comments by Jim Schaad, see https://www.ietf.org/		o Addressed review comments by Jim Schaad, see https://www.ietf.org/
	mail-archive/web/ace/current/msg02798.html		mail-archive/web/ace/current/msg02798.html
	o Removed unnecessary sentence in the introduction regarding the use		o Removed unnecessary sentence in the introduction regarding the use
	any strings that could be case-sensitive.		any strings that could be case-sensitive.
	o Clarified the terms Presenter and Recipient.		o Clarified the terms Presenter and Recipient.
	o Clarified text about the confirmation claim.		o Clarified text about the confirmation claim.
End of changes. 8 change blocks.
	21 lines changed or deleted		82 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/