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