Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
draft-ietf-ace-cwt-proof-of-possession-11

[Ballot comment]
Thank you for the work put into this document. The document is easy to read. I only one nit in section 3 and feel free to ignore all of it: While "sub" is explained as being the "subject", nothing is written about "iss" claim on the first time this term is used, it is only explained the 2nd time.

For my IESG colleagues, I second Mirja's comment about adding a IANA registry entry based on email.

Regards,

-éric

[Ballot comment]

Thanks for the work everyone put into defining this mechanism. I have one
very minor comment that the authors may wish to take into account.

§3.3:

>    /alg/ 3 : /HMAC256//256/ 5,

This use of "//" seems problematic, given RFC 8610's vague reservation of this
sequence for some kind of "comment to end of line" designation:

  (There are currently no end-of-line comments.  If we want to add
  them, "//" sounds like a reasonable delimiter given that we already
  use slashes for comments, but we could also go, for example,
  for "#".)

Given the potential ambiguity introduced by RFC 8610, perhaps
consider some other syntax here instead of "//".

[Ballot comment]
I would like to discuss one point with the IESG, however, not raising my ballot to "discuss" as I believe we can conclude quickly and this is not a major problem anyway.

So it seems to become more common to not only have expert review but also post a registration request on a public list and wait for a couple of weeks for comments. While I myself am uncertain if that is a good or bad practice (maybe also depends on the protocol), I would like to discuss this part in the IANA section:

  Registration requests sent to the mailing list for review should use
  an appropriate subject (e.g., "Request to Register CWT Confirmation
  Method: example").  Registration requests that are undetermined for a
  period longer than 21 days can be brought to the IESG's attention
  (using the iesg@ietf.org mailing list) for resolution.

I would think that, no matter what, registration request should be directed at IANA (and they would then post or forward to a mailing list and/or experts; or alternatively the experts can post than on the mailing list). I guess IANA would need to provide feedback here on what they prefer. However, for raising problems, of course everybody can always bring any problem to the IESG, but I think the first point of contact should also be IANA here. And then if no resolution can be find quickly for whatever reason, I would think that it's rather IANA that will bring this to the IESG (than the requesters directly).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ace-cwt-proof-of-possession-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the CBOR Web Token (CWT) Claims registry on the CBOR Web Token (CWT) Claims registry page, a single, new claim is to be registered as follows:

Claim Name: cnf
Claim Description: Confirmation
JWT Claim Name: cnf
Claim Key: [ TBD-at-Registration ]
Claim Value Type: map
Change Controller: IESG
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a Claim Key value of 8.

Second, a registry is to be created called the CWT Confirmation Methods registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

IANA Question --> How is this registry to be managed? The options in section 4 of RFC 8126 can be used as guidance for establishing a registration policy for the new registry.

IANA Question --> Section 7.2 says that the "registry records the confirmation method member and a reference to the specification that defines it." We're not sure what the word "member" is referring to here. Are there only two fields that the registry should record? If so, which ones? Alternatively, do you want us to record all of the fields in the registry, as we do for the CBOR Web Token (CWT) Claims registry at https://www.iana.org/assignments/cwt?

Depending on the answer to the question above, IANA recognizes that there are to be three initial entries in the new registry using the information provided in Section 7.2.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-10-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ace-cwt-proof-of-possession@ietf.org, rdd@cert.org, ace-chairs@ietf.org, kaduk@mit.edu, ace@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: -
'Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ballot/


No IPR declarations have been submitted directly on this I-D.

The following is the shepherd write-up for draft-ietf-ace-cwt-proof-of-possession-06.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of-possession key.  It is a functional equivalent to the proof of possession key semantics in JSON Web Tokens (JWTs) (RFC 7800) using CBOR/CWT.

The WG has reached consensus to publish this protocol specification as a Proposed Standard so that it tracks the equivalent work with JWTs (RFC 7800).  It has been subjected to review from the community of interest and the details have been testing through various CWT implementations.

2. Review and Consensus
=====================
This draft tracked the JSON Web Token (JWT) specification.  The WG adopted this draft in September 2017 (-00) from an individual submission which was first published in April 2017. 
WG convened WGLC on -02 of the draft in May 2018 (https://www.ietf.org/mail-archive/web/ace/current/msg02744.html).  Several months of discussion ensued to resolve the identified issues reflected in -03, -04 and -05.  Final nits were addressed in -06.

This draft builds upon the CWT specification (RFC8392) which has seen a variety of implementations:
** ACE-Java (Java) -- https://bitbucket.org/lseitz/ace-java
** CWT-JS (Javascript) -- https://github.com/erdtman/cwt-js
** node-cborwebtoken (Javascript) -- https://github.com/netnexus/node-cborwebtoken
** CWT (C#) -- https://github.com/Com-AugustCellars/CWT
** ChariWTs (Ruby) -- https://github.com/AnimaGUS-minerva/ChariWTs
** ARM Secure Device Access (SDA) -- https://cloud.mbed.com/docs/v1.2/device-management/secure-device-access.html

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the ACE mailing list:

** Michael Jones -- https://www.ietf.org/mail-archive/web/ace/current/msg03126.html
** Ludwig Seitz -- https://www.ietf.org/mail-archive/web/ace/current/msg03120.html
** Göran Selander -- https://www.ietf.org/mail-archive/web/ace/current/msg03125.html
** Sam Erdtman -- https://www.ietf.org/mail-archive/web/ace/current/msg03119.html
** Hannes Tschofenig -- https://www.ietf.org/mail-archive/web/ace/current/msg03121.html

There are no IPR disclosures on the document.

4. Other Points
============

Idnits reports the no issues that require action.

There are no yang modules present in this document requiring validation.

All examples (Section 3.2, 3.3 and 3.4) were validated with http://cbor.me/.

There are two actions for IANA:

(1) Registration of a new URI, urn:ietf:params:xml:ns:yang:ietf-dots-data-channel, in the “IETF XML Registry"; and
(2) Registration of new YANG module, ietf-dots-data-channel, in the “YANG Module Names” registry

No early expert review has been requested for the above IANA allocation.

(11/30/2018, awaiting document update per items found during shepherd review:
** https://www.ietf.org/mail-archive/web/ace/current/msg03127.html
** https://www.ietf.org/mail-archive/web/ace/current/msg03124.html)

The following is the shepherd write-up for draft-ietf-ace-cwt-proof-of-possession-05.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of-possession key.  It is a functional equivalent to the proof of possession key semantics in JSON Web Tokens (JWTs) (RFC 7800) using CBOR/CWT.

The WG has reached consensus to publish this protocol specification as a Proposed Standard so that it tracks the equivalent work with JWTs (RFC 7800).  It has been subjected to review from the community of interest and the details have been testing through various CWT implementations.

2. Review and Consensus
=====================
This draft tracked the JSON Web Token (JWT) specification.  The WG adopted this draft in September 2017 (-00) from an individual submission which was first published in April 2017. 
WG convened WGLC on -02 of the draft in May 2018 (https://www.ietf.org/mail-archive/web/ace/current/msg02744.html).  Several months of discussion ensued to resolve the identified issues reflected in -03, -04 and -05.  Final nits were addressed in -06.

This draft builds upon the CWT specification (RFC8392) which has seen a variety of implementations:
** ACE-Java (Java) -- https://bitbucket.org/lseitz/ace-java
** CWT-JS (Javascript) -- https://github.com/erdtman/cwt-js
** node-cborwebtoken (Javascript) -- https://github.com/netnexus/node-cborwebtoken
** CWT (C#) -- https://github.com/Com-AugustCellars/CWT
** ChariWTs (Ruby) -- https://github.com/AnimaGUS-minerva/ChariWTs
** ARM Secure Device Access (SDA) -- https://cloud.mbed.com/docs/v1.2/device-management/secure-device-access.html

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the ACE mailing list:

** Michael Jones -- https://www.ietf.org/mail-archive/web/ace/current/msg03126.html
** Ludwig Seitz -- https://www.ietf.org/mail-archive/web/ace/current/msg03120.html
** Göran Selander -- https://www.ietf.org/mail-archive/web/ace/current/msg03125.html
** Sam Erdtman -- https://www.ietf.org/mail-archive/web/ace/current/msg03119.html
** Hannes Tschofenig -- https://www.ietf.org/mail-archive/web/ace/current/msg03121.html

There are no IPR disclosures on the document.

4. Other Points
============

Idnits reports the following issues which do not require action:

[insert]

There are no yang modules present in this document requiring validation.

All examples were with http://cbor.me/

There are two actions for IANA:

(1) Registration of a new URI, urn:ietf:params:xml:ns:yang:ietf-dots-data-channel, in the “IETF XML Registry"; and
(2) Registration of new YANG module, ietf-dots-data-channel, in the “YANG Module Names” registry

No early expert review has been requested for the above IANA allocation.

Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Erik Wahlstroem , Hannes Tschofenig , Michael Jones , Goeran Selander , Samuel Erdtman , Ludwig Seitz

Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Erik Wahlstroem , Hannes Tschofenig , Michael Jones , Goeran Selander , Samuel Erdtman , Ludwig Seitz

Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Erik Wahlstroem , Hannes Tschofenig , Michael Jones , Goeran Selander , Samuel Erdtman , Ludwig Seitz