Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

[Jim Schaad]

 

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Wednesday, April 5, 2017 6:02 PM
To: Samuel Erdtman ; Jim Schaad 
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace 
Subject: RE: [Ace] Review of draft-ietf-ace-cbor-web-token-03

 

Let me second the thanks for the thorough review, Jim, and especially for 
validating the examples.  Replies to some of the points are inline…

 

-- Mike

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad  >
Cc: draft-ietf-ace-cbor-web-to...@ietf.org 
 ; ace  >
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

 

Thanks for the review Jim,

See inline comments

 

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad  > wrote:

Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.

1.  Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures.  Language
about different applications extending this structure would also be
reasonable.

 

I was not part of that discussion, could you please link to some resource or 
notes from that meeting.

In the SecEvent WG, after I gave this invited presentation on JOSE/JWT security 

 , there was a discussion on whether it would be useful to document best 
practices on using JWTs.  After the repeating the same presentation in the 
OAuth working group, it was agreed that we would do that and I would write down 
some of the possible issues using JWTs and mitigations.  Some of this will be 
in the form of advice to implementers.  Some of it will be advice to protocol 
designers.  Given that CWTs are intentionally parallel to JWTs, I expect that 
much of the JWT BCP language will also apply to CWTs.  I’ll make a mental note 
to also be thinking about CWTs when writing about JWTs.

 

 

2.  I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not.  I do no remember seeing any
discussions on the list but have not gone back to search

 

We have no looked at changing this. Is there any good motivation for actually 
doing this change?

 

Having it just be a string as it is now is parallel with JWTs (which don’t have 
the tagging option available to them). My inclination is to keep it parallel.  
Alternatively, we could say that it’s also legal to tag the value as a URI if 
it is one.  What do others think?

 


3.  I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.

 

I think the idea is to say that it is not a JSON number but a CBOR number. I 
have added a ticket to look at the wording.
https://github.com/erwah/ietf/issues/28

I agree that clearer wording can be used, talking about a CBOR number tagged as 
a numeric date. 

 


4.  The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do.  All of the examples are incorrect
because of this tag usage.

 

Examples should be updated, see below

 


5.  After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?

 

I have not seen the SET group discussion could you please link to it.

 

Ignoring claims that are not understood is critical to extensibility.  It’s 
served JWTs well and will serve CWTs well in the same regard.  Without this, 
every system using a CWT would be brittle by design.

 


6.  The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics.   This would be clearer than what is
written.


Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/26
 


7.  The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.

 

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/25

 

I disagree with this.  The values in the registry are already marked as “TBD 
(maybe 61)”.  It would just add clutter, detracting from the readability of the 
spec, to replicate this elsewhere.  Besides, the examples need a specific 
number.  If IANA changes the number, we will of course, update the spec 
accordingly, once a final assignment is determined.

 

 

[JLS] – This is the definition of point squatting.  Looking at the registry, 
the correct thing to do is to use 

Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

[Mike Jones]

Let me second the thanks for the thorough review, Jim, and especially for 
validating the examples.  Replies to some of the points are inline…

-- Mike

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad 
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace 
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

Thanks for the review Jim,
See inline comments

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad 
> wrote:
Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.

1.  Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures.  Language
about different applications extending this structure would also be
reasonable.

I was not part of that discussion, could you please link to some resource or 
notes from that meeting.

In the SecEvent WG, after I gave this invited presentation on JOSE/JWT 
security,
 there was a discussion on whether it would be useful to document best 
practices on using JWTs.  After the repeating the same presentation in the 
OAuth working group, it was agreed that we would do that and I would write down 
some of the possible issues using JWTs and mitigations.  Some of this will be 
in the form of advice to implementers.  Some of it will be advice to protocol 
designers.  Given that CWTs are intentionally parallel to JWTs, I expect that 
much of the JWT BCP language will also apply to CWTs.  I’ll make a mental note 
to also be thinking about CWTs when writing about JWTs.


2.  I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not.  I do no remember seeing any
discussions on the list but have not gone back to search

We have no looked at changing this. Is there any good motivation for actually 
doing this change?

Having it just be a string as it is now is parallel with JWTs (which don’t have 
the tagging option available to them). My inclination is to keep it parallel.  
Alternatively, we could say that it’s also legal to tag the value as a URI if 
it is one.  What do others think?


3.  I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.

I think the idea is to say that it is not a JSON number but a CBOR number. I 
have added a ticket to look at the wording.
https://github.com/erwah/ietf/issues/28
I agree that clearer wording can be used, talking about a CBOR number tagged as 
a numeric date.


4.  The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do.  All of the examples are incorrect
because of this tag usage.

Examples should be updated, see below


5.  After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?

I have not seen the SET group discussion could you please link to it.

Ignoring claims that are not understood is critical to extensibility.  It’s 
served JWTs well and will serve CWTs well in the same regard.  Without this, 
every system using a CWT would be brittle by design.


6.  The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics.   This would be clearer than what is
written.

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/26


7.  The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/25

I disagree with this.  The values in the registry are already marked as “TBD 
(maybe 61)”.  It would just add clutter, detracting from the readability of the 
spec, to replicate this elsewhere.  Besides, the examples need a specific 
number.  If IANA changes the number, we will of course, update the spec 
accordingly, once a final assignment is determined.

8.  The note for step 5 in section 6.1 is problematic from a number of
things.  A) AEAD algorithms are required, so it is not clear that the
recommendation makes sense.  B) there is a big difference between signing
and MACing in terms of the amount and type of integrity provided.  Replacing
signing w/ AEAD loses a lot.

I think you are correct and I have considered removing it, I added in in an 
early attempt to be smart.
I have added a issue to evaluate the value of this statement and remove if 
considered useless.
https://github.com/erwah/ietf/issues/24

I agree with deleting it.


9.  Step 6