--- 1/draft-ietf-ace-cwt-proof-of-possession-01.txt 2018-03-03 16:13:13.439050902 -0800 +++ 2/draft-ietf-ace-cwt-proof-of-possession-02.txt 2018-03-03 16:13:13.471051656 -0800 @@ -1,27 +1,27 @@ ACE Working Group M. Jones Internet-Draft Microsoft Intended status: Standards Track L. Seitz -Expires: May 3, 2018 RISE SICS +Expires: September 4, 2018 RISE SICS G. Selander Ericsson AB E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig ARM Ltd. - October 30, 2017 + March 3, 2018 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 This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs. @@ -34,25 +34,25 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -60,55 +60,55 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Representations for Proof-of-Possession Keys . . . . . . . . 3 3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4 3.2. Representation of an Asymmetric Proof-of-Possession Key . 5 3.3. Representation of an Encrypted Symmetric Proof-of- - Possession Key . . . . . . . . . . . . . . . . . . . . . 5 - 3.4. Representation of a Key ID for a Proof-of-Possession Key 6 + Possession Key . . . . . . . . . . . . . . . . . . . . . 6 + 3.4. Representation of a Key ID for a Proof-of-Possession Key 7 3.5. Specifics Intentionally Not Specified . . . . . . . . . . 7 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. CBOR Web Token Claims Registration . . . . . . . . . . . 9 - 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 9 - 6.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 9 + 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 10 + 6.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 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.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 - Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Document History . . . . . . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This specification describes how a CBOR Web Token [CWT] can declare that the presenter of the CWT possesses a particular proof-of- possession (PoP) key. Proof of possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" [RFC7800], but using CBOR [RFC7049] and CWTs [CWT] rather than JSON [RFC7159] and JWTs [JWT]. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. + "OPTIONAL" in this document are to be interpreted as described in BCP + 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 are case sensitive. 2. Terminology This specification uses terms defined in the CBOR Web Token [CWT], CBOR Object Signing and Encryption (COSE) [RFC8152], and Concise Binary Object Representation (CBOR) [RFC7049] specifications. @@ -204,22 +204,24 @@ Claims Set of a CWT: { /iss/ 1 : "coaps://server.example.com", /aud/ 3 : "coaps://client.example.org", /exp/ 4 : 1361398824, /cnf/ 8 :{ /COSE_Key/ 1 :{ /kty/ 1 : /EC/ 2, /crv/ -1 : /P-256/ 1, - /x/ -2 : b64'18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM', - /y/ -3 : b64'-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA' + /x/ -2 : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa27c9 + e354089bbe13', + /y/ -3 : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020731e + 79a3b4e47120' } } } 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 "kid" (Key ID) member. 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 @@ -295,21 +297,21 @@ /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' } } The content of the "kid" value is application specific. For instance, some applications may choose to use a cryptographic hash of the public key value as the "kid" value. 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 the presenter. This value is sometimes called a "nonce" or a "challenge". The means of communicating the nonce and the nature of its contents are intentionally not described in this specification, as different protocols will communicate this information in different ways. Likewise, the means of communicating the signed nonce is also not specified, as this is also protocol specific. @@ -485,23 +487,23 @@ o Confirmation Value Type(s): binary string o Change Controller: IESG o Specification Document(s): Section 3.4 of [[ this document ]] 7. References 7.1. Normative References [CWT] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", Work in Progress, draft-ietf-ace- - cbor-web-token-07, June 2017, + cbor-web-token-11, January 2018, . + draft-ietf-ace-cbor-web-token-11>. [IANA.CWT.Claims] IANA, "CBOR Web Token Claims", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -532,20 +534,24 @@ 2011, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 7.2. Informative References [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, . @@ -567,38 +573,43 @@ [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . Acknowledgements Thanks to the following people for their reviews of the specification: Michael Richardson and Jim Schaad. -Open Issues - - o Convert the examples from JSON/JWT to CBOR/CWT. - Document History [[ 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 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 Michael B. Jones Microsoft Email: mbj@microsoft.com URI: http://self-issued.info/