draft-ietf-ace-cwt-proof-of-possession-09.txt | draft-ietf-ace-cwt-proof-of-possession-10.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: April 20, 2020 RISE SICS | Expires: May 2, 2020 RISE SICS | |||
G. Selander | G. Selander | |||
Ericsson AB | Ericsson AB | |||
S. Erdtman | S. Erdtman | |||
Spotify | Spotify | |||
H. Tschofenig | H. Tschofenig | |||
Arm Ltd. | Arm Ltd. | |||
October 18, 2019 | October 30, 2019 | |||
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-09 | draft-ietf-ace-cwt-proof-of-possession-10 | |||
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 | |||
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 April 20, 2020. | This Internet-Draft will expire on May 2, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 4, line 10 ¶ | skipping to change at page 4, line 10 ¶ | |||
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" claim | identify the presenter. Other applications may use the "iss" | |||
to identify the presenter. In some applications, the subject | (issuer) claim [RFC8392] to identify the presenter. In some | |||
identifier might be relative to the issuer identified by the "iss" | applications, the subject identifier might be relative to the issuer | |||
(issuer) claim [RFC8392]. The actual mechanism used is dependent | identified by the "iss" claim. The actual mechanism used is | |||
upon the application. The case in which the presenter is the subject | dependent upon the application. The case in which the presenter is | |||
of the CWT is analogous to Security Assertion Markup Language (SAML) | the subject of the CWT is analogous to Security Assertion Markup | |||
2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation usage. | Language (SAML) 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation | |||
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). | |||
skipping to change at page 6, line 17 ¶ | skipping to change at page 6, line 17 ¶ | |||
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 : /HMAC256//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: | |||
skipping to change at page 14, line 24 ¶ | skipping to change at page 14, line 24 ¶ | |||
[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, Yoav | specification: Roman Danyliw, Christer Holmberg, Benjamin Kaduk, | |||
Nir, Michael Richardson, and Jim Schaad. | Mirja Kuehlewind, Yoav Nir, Michael Richardson, Adam Roach, Eric | |||
Vyncke, 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 projects CyberWI and CRITISEC, with funding from | the CelticPlus projects CyberWI and CRITISEC, with funding from | |||
Vinnova. | 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 ]] | |||
-10 | ||||
o Addressed IESG review comments by Adam Roach and Eric Vyncke. | ||||
-09 | -09 | |||
o Addressed Gen-ART review comments by Christer Holmberg and SecDir | o Addressed Gen-ART review comments by Christer Holmberg and SecDir | |||
review comments by Yoav Nir. | review comments by Yoav Nir. | |||
-08 | -08 | |||
o Addressed remaining Area Director review comments by Benjamin | o Addressed remaining Area Director review comments by Benjamin | |||
Kaduk. | Kaduk. | |||
End of changes. 8 change blocks. | ||||
14 lines changed or deleted | 20 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |