Diff: draft-ietf-ace-cwt-proof-of-possession-01.txt - draft-ietf-ace-cwt-proof-of-possession-02.txt

	draft-ietf-ace-cwt-proof-of-possession-01.txt	draft-ietf-ace-cwt-proof-of-possession-02.txt

	ACE Working Group M. Jones	ACE Working Group M. Jones
	Internet-Draft Microsoft	Internet-Draft Microsoft
	Intended status: Standards Track L. Seitz	Intended status: Standards Track L. Seitz

	Expires: May 3, 2018 RISE SICS	Expires: September 4, 2018 RISE SICS
	G. Selander	G. Selander
	Ericsson AB	Ericsson AB
	E. Wahlstroem	E. Wahlstroem

	S. Erdtman	S. Erdtman
	Spotify AB	Spotify AB
	H. Tschofenig	H. Tschofenig
	ARM Ltd.	ARM Ltd.

	October 30, 2017	March 3, 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-01	draft-ietf-ace-cwt-proof-of-possession-02

	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 45 ¶	skipping to change at page 1, line 45 ¶
	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 3, 2018.	This Internet-Draft will expire on September 4, 2018.

	Copyright Notice	Copyright Notice


	Copyright (c) 2017 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
	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

	skipping to change at page 2, line 29 ¶	skipping to change at page 2, line 29 ¶

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . 6
	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 7
	3.5. Specifics Intentionally Not Specified . . . . . . . . . . 7	3.5. Specifics Intentionally Not Specified . . . . . . . . . . 7

	4. Security Considerations . . . . . . . . . . . . . . . . . . . 7	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6.1. CBOR Web Token Claims Registration . . . . . . . . . . . 9	6.1. CBOR Web Token Claims Registration . . . . . . . . . . . 9

	6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 9	6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 10
	6.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 9	6.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 10
	6.2.1. Registration Template . . . . . . . . . . . . . . . . 10	6.2.1. Registration Template . . . . . . . . . . . . . . . . 10

	6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 10	6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . 11	7.1. Normative References . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . 12	7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13

	Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Document History . . . . . . . . . . . . . . . . . . . . . . . . 13	Document History . . . . . . . . . . . . . . . . . . . . . . . . 13

	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14

	1. Introduction	1. Introduction

	This specification describes how a CBOR Web Token [CWT] can declare	This specification describes how a CBOR Web Token [CWT] can declare
	that the presenter of the CWT possesses a particular proof-of-	that the presenter of the CWT possesses a particular proof-of-
	possession (PoP) key. Proof of possession of a key is also sometimes	possession (PoP) key. Proof of possession of a key is also sometimes
	described as being the holder-of-key. This specification provides	described as being the holder-of-key. This specification provides
	equivalent functionality to "Proof-of-Possession Key Semantics for	equivalent functionality to "Proof-of-Possession Key Semantics for
	JSON Web Tokens (JWTs)" [RFC7800], but using CBOR [RFC7049] and CWTs	JSON Web Tokens (JWTs)" [RFC7800], but using CBOR [RFC7049] and CWTs
	[CWT] rather than JSON [RFC7159] and JWTs [JWT].	[CWT] rather than JSON [RFC7159] and JWTs [JWT].

	1.1. Notational Conventions	1.1. Notational Conventions

	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	"OPTIONAL" in this document are to be interpreted as described in BCP
	[RFC2119].	14 [RFC2119] [RFC8174] when, and only when, they appear in all
		capitals, as shown here.

	Unless otherwise noted, all the protocol parameter names and values	Unless otherwise noted, all the protocol parameter names and values
	are case sensitive.	are case sensitive.

	2. Terminology	2. Terminology

	This specification uses terms defined in the CBOR Web Token [CWT],	This specification uses terms defined in the CBOR Web Token [CWT],
	CBOR Object Signing and Encryption (COSE) [RFC8152], and Concise	CBOR Object Signing and Encryption (COSE) [RFC8152], and Concise
	Binary Object Representation (CBOR) [RFC7049] specifications.	Binary Object Representation (CBOR) [RFC7049] specifications.


	skipping to change at page 5, line 23 ¶	skipping to change at page 5, line 23 ¶
	Figure 1: Summary of the cnf names, keys, and value types	Figure 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 (using	corresponding asymmetric public key. The following example (using
	CBOR diagonstic notation) demonstrates such a declaration in the CWT	CBOR diagonstic notation) demonstrates such a declaration in the CWT
	Claims Set of a 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 : 1361398824,	/exp/ 4 : 1361398824,
	/cnf/ 8 :{	/cnf/ 8 :{
	/COSE_Key/ 1 :{	/COSE_Key/ 1 :{
	/kty/ 1 : /EC/ 2,	/kty/ 1 : /EC/ 2,
	/crv/ -1 : /P-256/ 1,	/crv/ -1 : /P-256/ 1,
	/x/ -2 : b64'18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM',	/x/ -2 : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa27c9
	/y/ -3 : b64'-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA'	e354089bbe13',
	}	/y/ -3 : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020731e
	}	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 [CWT]. If the CWT is not encrypted, the symmetric key	explained in [CWT]. If the CWT is not encrypted, the symmetric key
	MUST be encrypted as described below.	MUST be encrypted as described below.

	skipping to change at page 7, line 25 ¶	skipping to change at page 7, line 34 ¶
	/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.

	3.5. Specifics Intentionally Not Specified	3.5. Specifics Intentionally Not Specified


	Proof of possession is typically 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.
	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.


	skipping to change at page 11, line 23 ¶	skipping to change at page 11, line 40 ¶
	o Confirmation Value Type(s): binary string	o Confirmation Value Type(s): binary string
	o Change Controller: IESG	o Change Controller: IESG
	o Specification Document(s): Section 3.4 of [[ this document ]]	o Specification Document(s): Section 3.4 of [[ this document ]]

	7. References	7. References

	7.1. Normative References	7.1. Normative References

	[CWT] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,	[CWT] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", Work in Progress, draft-ietf-ace-	"CBOR Web Token (CWT)", Work in Progress, draft-ietf-ace-

	cbor-web-token-07, June 2017,	cbor-web-token-11, January 2018,
	<https://tools.ietf.org/html/	<https://tools.ietf.org/html/

	draft-ietf-ace-cbor-web-token-07>.	draft-ietf-ace-cbor-web-token-11>.

	[IANA.CWT.Claims]	[IANA.CWT.Claims]
	IANA, "CBOR Web Token Claims",	IANA, "CBOR Web Token Claims",
	<http://www.iana.org/assignments/cwt>.	<http://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>.


	skipping to change at page 12, line 25 ¶	skipping to change at page 12, line 39 ¶
	2011, <https://www.rfc-editor.org/info/rfc6125>.	2011, <https://www.rfc-editor.org/info/rfc6125>.

	[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>.

	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,	RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.	<https://www.rfc-editor.org/info/rfc8152>.


		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
		May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	7.2. Informative References	7.2. Informative References

	[IANA.JWT.Claims]	[IANA.JWT.Claims]
	IANA, "JSON Web Token Claims",	IANA, "JSON Web Token Claims",
	<http://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, May 2015,	Signature (JWS)", RFC 7515, May 2015,
	<http://www.rfc-editor.org/info/rfc7515>.	<http://www.rfc-editor.org/info/rfc7515>.


	skipping to change at page 13, line 15 ¶	skipping to change at page 13, line 30 ¶
	[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>.

	Acknowledgements	Acknowledgements

	Thanks to the following people for their reviews of the	Thanks to the following people for their reviews of the
	specification: Michael Richardson and Jim Schaad.	specification: Michael Richardson and Jim Schaad.


	Open Issues

	o Convert the examples from JSON/JWT to CBOR/CWT.

	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 ]]


		-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	-01

	o Now uses CBOR diagnostic notation for the examples.	o Now uses CBOR diagnostic notation for the examples.

	o Added a table summarizing the "cnf" names, keys, and value types.	o Added a table summarizing the "cnf" names, keys, and value types.

	o Addressed some of Jim Schaad's feedback on -00.	o Addressed some of Jim Schaad's feedback on -00.

	-00	-00


	o Created the initial working group draft from draft-jones-ace-cwt-	o Created the initial working group draft from draft-jones-ace-cwt-
	proof-of-possession-01.	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: http://self-issued.info/

End of changes. 20 change blocks.
	38 lines changed or deleted	49 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/