< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/