Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

From: [email-masked]
Date: Mon, 05 Jun 2017 18:26:34 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for Constrained Environments of the IETF.

        Title           : CBOR Web Token (CWT)
        Authors         : Michael B. Jones
                          Erik Wahlström
                          Samuel Erdtman
                          Hannes Tschofenig
	Filename        : draft-ietf-ace-cbor-web-token-05.txt
	Pages           : 23
	Date            : 2017-06-05

Abstract:
   CBOR Web Token (CWT) is a compact means of representing claims to be
   transferred between two parties.  The claims in a CWT are encoded in
   the Concise Binary Object Representation (CBOR) and CBOR Object
   Signing and Encryption (COSE) is used for added application layer
   security protection.  A claim is a piece of information asserted
   about a subject and is represented as a name/value pair consisting of
   a claim name and a claim value.  CWT is derived from JSON Web Token
   (JWT), but uses CBOR rather than JSON.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05
https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jim Schaad <[email-masked]>
Date: Sun, 18 Jun 2017 12:21:28 -0700

Comments on this version of the draft.

Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR tag at this point

Section 7 - In Step 7 - it must be a valid CBOR map not just a valid CBOR object.

Appendix A.3 - I was unable to reproduce the example.  I assume that this means that a deterministic signature algorithm is not being used.  While a verifier cannot tell if one is being used, the COSE document does strongly suggest that one be used.  Additionally, it helps in testing if one is used so that a signature creator can be more easily tested.

Appendix A.5 - I was unable to reproduce the example.  Specially the tag value does not match with the one that I compute.

Appendix A.6 - I did not try to reproduce given that a) I would not generate the same signature and b) the example A.5 failed.

Minor:

In section 1.1 s/In COSE/In CBOR/ - this is a comment on CBOR not on COSE

In section 2:  s/CBOR encoded claim key/CBOR claim key/  
	* I am unsure why you would think that encoded is needed here. 
	* Should this be CWT rather than CBOR?
	* Why is section 3.1 "Claim Names" rather than "Claim Keys"

In section 2:  Is there a reason not to define CWT claim value in this section

In section 3.1.1 and on - the following might be considered cleaner s/except that the format MUST be a/except that the value MUST be of type/

Section 9.1.2 - I would suggest assigning a name to the reserved entry

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 5, 2017 6:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 22 Jun 2017 10:40:04 +0200

Thanks Jim!

Se comments inline

> Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR

In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the
full CWT if transport layer cannot indicate that this is a CWT. In this
case you would want first the COSE tag and then the CWT tag this is
described in section 6. We asked Carsten about this before we added the
text so it should be okay.

In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can
tell.

> Section 7 - In Step 7 - it must be a valid CBOR map not just a valid CBOR

Good catch I´ll fix, Issue create for now.

>
> Appendix A.3 - I was unable to reproduce the example.  I assume that this
> means that a deterministic signature algorithm is not being used.  While a
> verifier cannot tell if one is being used, the COSE document does strongly
> suggest that one be used.  Additionally, it helps in testing if one is used
> so that a signature creator can be more easily tested.
>

Correct I have not used a deterministic signing algorithm. I have used
COSE-JAVA to create the examples, is it possible to configure that
implementation to generate deterministic ECDSA signatures?
When working with my JS implementation I have noticed that support for
deterministic ECDSA implementations are hard to find.

>
> Appendix A.5 - I was unable to reproduce the example.  Specially the tag
> value does not match with the one that I compute.
>

That is bad. but apart from the tag it looks good?

>
> Appendix A.6 - I did not try to reproduce given that a) I would not
> generate the same signature and b) the example A.5 failed.
>

See comments above.

> In section 1.1 s/In COSE/In CBOR/ - this is a comment on CBOR not on COSE

Good catch. However I think it should be s/In COSE/In CWT/, I have created
an issue to fix this.

>         * Why is section 3.1 "Claim Names" rather than "Claim Keys"

I have created an issue to address this.
I think the name of section 3.1 is legacy from JWT where the equivalent
section is called "Registered Claim Names" I would like to change the name
to just "Registered Claims" since it is not just he names or the key that
is registered also value type.

> In section 2:  Is there a reason not to define CWT claim value in this

Sorry I´m not following, could you please explain a bit more`?

> In section 3.1.1 and on - the following might be considered cleaner
> s/except that the format MUST be a/except that the value MUST be of type/
>

I have created an issue for this to be considered

> Section 9.1.2 - I would suggest assigning a name to the reserved entry

I have created an issue for this to be considered

> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 22 Jun 2017 15:08:45 -0700

See below.

Jim

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Thursday, June 22, 2017 1:40 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; ace <[email-masked]>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

Thanks Jim! 

Se comments inline

On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the full CWT if transport layer cannot indicate that this is a CWT. In this case you would want first the COSE tag and then the CWT tag this is described in section 6. We asked Carsten about this before we added the text so it should be okay.

In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can tell.

[JLS]  So if an intermediary adds a layer of wrapping (i.e. encrypts it to the end point) but the original entity who signed it put the CWT tag on it, it will be and invalid CWT if the tag was not removed? 

Correct I have not used a deterministic signing algorithm. I have used COSE-JAVA to create the examples, is it possible to configure that implementation to generate deterministic ECDSA signatures? 
When working with my JS implementation I have noticed that support for deterministic ECDSA implementations are hard to find.

[JLS] With COSE-JAVA, if you are using anything remotely recent is deterministic, so that should not be a problem.  I put this change into the sources about 8 months ago.  The problem may be the same issue as for A.5 where something is different in the data to be signed.  

[JLS] Yes apart from the tag I matched everything – including the encryption.  This bothers me if you are using the COSE-JAVA to produce the examples.  I routinely run regression tests on both language libraries so they should produce the same output given the same inputs.  This triggers in my mind that you might have done something odd with the external data and thus we are generating different tags.   It would be something that is being done for signing and for encryption but not mac.

Minor:

[JLS] You thought it was reasonable to define a “CWT encoded claim key” in the terms.  I was just thinking that it would be symmetric to have the values have defined here at the same time.

-----Original Message-----
From: Ace [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: Monday, June 5, 2017 6:27 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace