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

From: Samuel Erdtman <[email-masked]>
Date: Mon, 3 Apr 2017 07:58:25 +0200

Thanks for the review Jim,

See inline comments

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad <[email-masked]> 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.

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?

>
> 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

>
> 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.

>
> 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

>
> 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

>
> 9.  Step 6 in section 6.1 does not agree w/ the language in section 5.
> MUST
> vs maybe.
>

I see your point. I have added a ticket to look over the create and verify
steps to make sure they are consistent.
https://github.com/erwah/ietf/issues/27

>
> 10.  In starting to verify the examples I ran across the following two
> issues:
>
> a) The hex string and the diagnostic notation are equivalent, but they are
> not the same.  Specifically, the order of claims is not the same.  CBOR.ME
> gives
>
> {2: "erikw", 3: "coap://light.example.com", 4: 1444064944, 5: 1443944944,
> 6:
> 1443944944, 1: "coap://as.example.com", 7: h'0b71'}
>

I have create a issue to make them the same to make reading and testing
easier, https://github.com/erwah/ietf/issues/23

>
> b) The encoding of some of the claims is incorrect according to the
> document.  It should be
>

You are correct, I have added an issue to update,
https://github.com/erwah/ietf/issues/22

>
> { 1: "coap://as.example.com", 2: "erikw", 3: "coap://light.example.com",
> 4:
> 1(1444064944), 5: 1(1443944944), 6: 1(1443944944),7: h'0b71'}
>
> Or
>
> a7                                      # map(7)
>    01                                   # unsigned(1)
>    75                                   # text(21)
>       636f61703a2f2f61732e6578616d706c652e636f6d # "coap://as.example.com"
>    02                                   # unsigned(2)
>    65                                   # text(5)
>       6572696b77                        # "erikw"
>    03                                   # unsigned(3)
>    78 18                                # text(24)
>       636f61703a2f2f6c696768742e6578616d706c652e636f6d #
> "coap://light.example.com"
>    04                                   # unsigned(4)
>    c1                                   # tag(1)
>       1a 5612aeb0                       # unsigned(1444064944)
>    05                                   # unsigned(5)
>    c1                                   # tag(1)
>       1a 5610d9f0                       # unsigned(1443944944)
>    06                                   # unsigned(6)
>    c1                                   # tag(1)
>       1a 5610d9f0                       # unsigned(1443944944)
>    07                                   # unsigned(7)
>    42                                   # bytes(2)
>       0b71                              # "\vq"
>
> Note the additional tagging which is required.
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 3 Apr 2017 07:36:18 -0700

It has been pointed out to me that I was incorrect when I thought that the TLA for the WG was SET.  It should be secevent.

Jim

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; ace <[email-masked]>
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

See inline comments

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

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

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

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

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

and MACing in terms of the amount and type of integrity provided.  Replacing

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

9.  Step 6 in section 6.1 does not agree w/ the language in section 5.  MUST
vs maybe.

I see your point. I have added a ticket to look over the create and verify steps to make sure they are consistent.
https://github.com/erwah/ietf/issues/27

a) The hex string and the diagnostic notation are equivalent, but they are
not the same.  Specifically, the order of claims is not the same.  CBOR.ME <http://CBOR.ME> 
gives

{2: "erikw", 3: "coap://light.example.com <http://light.example.com> ", 4: 1444064944, 5: 1443944944, 6:
1443944944, 1: "coap://as.example.com <http://as.example.com> ", 7: h'0b71'}

I have create a issue to make them the same to make reading and testing easier, https://github.com/erwah/ietf/issues/23

You are correct, I have added an issue to update, https://github.com/erwah/ietf/issues/22

{ 1: "coap://as.example.com <http://as.example.com> ", 2: "erikw", 3: "coap://light.example.com <http://light.example.com> ", 4:
1(1444064944), 5: 1(1443944944), 6: 1(1443944944),7: h'0b71'}

Or

a7                                      # map(7)
   01                                   # unsigned(1)
   75                                   # text(21)
      636f61703a2f2f61732e6578616d706c652e636f6d # "coap://as.example.com <http://as.example.com> "
   02                                   # unsigned(2)
   65                                   # text(5)
      6572696b77                        # "erikw"
   03                                   # unsigned(3)
   78 18                                # text(24)
      636f61703a2f2f6c696768742e6578616d706c652e636f6d #
"coap://light.example.com <http://light.example.com> "
   04                                   # unsigned(4)
   c1                                   # tag(1)
      1a 5612aeb0                       # unsigned(1444064944)
   05                                   # unsigned(5)
   c1                                   # tag(1)
      1a 5610d9f0                       # unsigned(1443944944)
   06                                   # unsigned(6)
   c1                                   # tag(1)
      1a 5610d9f0                       # unsigned(1443944944)
   07                                   # unsigned(7)
   42                                   # bytes(2)
      0b71                              # "\vq"

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 4 Apr 2017 07:31:31 -0700

Some comments inline

See inline comments

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

[JLS] As noted in an earlier message, I got the name of the WG wrong.  The document is SET and the WG is secevent.  Given that Mike was doing the presentation, I would suggest talking to him about the issues presented.  The issues involved how to prevent a SET being used as a JWT as an access token.

[JLS] If you tagged URIs, which is presumably easy for the creator, then the recipient does not have to do any work to try and distinguish between a string and a URI.  The cost is that the token is going to be one byte longer per tag.  This is not done for JWT and therefore code needs to exist on the user of a JWT to figure out if it is a URI.

 

[JLS] You can find some candidate encodings in the examples github for COSE.

Jim

Or

a7                                      # map(7)
   01                                   # unsigned(1)
   75                                   # text(21)

---

From: Mike Jones <[email-masked]>
Date: Thu, 6 Apr 2017 01:01:59 +0000

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

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

In the SecEvent WG, after I gave this invited presentation on JOSE/JWT security<https://www.ietf.org/proceedings/98/slides/slides-98-secevent-josejwt-security-update-00.pdf>, 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.

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?

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.

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.

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.

I agree with deleting it.

Section 5 says that use of the CBOR tag is optional.  But I see that the language “The CWT tag MUST prefix a tagged object” could be misinterpreted.  We could change this to “If present, the CWT tag MUST prefix a tagged object”.

a) The hex string and the diagnostic notation are equivalent, but they are
not the same.  Specifically, the order of claims is not the same.  CBOR.ME<http://CBOR.ME>
gives

{2: "erikw", 3: "coap://light.example.com<http://light.example.com>", 4: 1444064944, 5: 1443944944, 6:
1443944944, 1: "coap://as.example.com<http://as.example.com>", 7: h'0b71'}

{ 1: "coap://as.example.com<http://as.example.com>", 2: "erikw", 3: "coap://light.example.com<http://light.example.com>", 4:
1(1444064944), 5: 1(1443944944), 6: 1(1443944944),7: h'0b71'}

Or

a7                                      # map(7)
   01                                   # unsigned(1)
   75                                   # text(21)
      636f61703a2f2f61732e6578616d706c652e636f6d # "coap://as.example.com<http://as.example.com>"
   02                                   # unsigned(2)
   65                                   # text(5)
      6572696b77                        # "erikw"
   03                                   # unsigned(3)
   78 18                                # text(24)
      636f61703a2f2f6c696768742e6578616d706c652e636f6d #
"coap://light.example.com<http://light.example.com>"
   04                                   # unsigned(4)
   c1                                   # tag(1)
      1a 5612aeb0                       # unsigned(1444064944)
   05                                   # unsigned(5)
   c1                                   # tag(1)
      1a 5610d9f0                       # unsigned(1443944944)
   06                                   # unsigned(6)
   c1                                   # tag(1)
      1a 5610d9f0                       # unsigned(1443944944)
   07                                   # unsigned(7)
   42                                   # bytes(2)
      0b71                              # "\vq"

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 5 Apr 2017 18:32:11 -0700

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, April 5, 2017 6:02 PM
To: Samuel Erdtman <[email-masked]>; Jim Schaad <[email-masked]>
Cc: [email-masked]; ace <[email-masked]>
Subject: RE: [Ace] Review of draft-ietf-ace-cbor-web-token-03

                                                                -- Mike

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; ace <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

See inline comments

In the SecEvent WG, after I gave this invited presentation on JOSE/JWT security <https://www.ietf.org/proceedings/98/slides/slides-98-secevent-josejwt-security-update-00.pdf> , 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.

 

[JLS] – This is the definition of point squatting.  Looking at the registry, the correct thing to do is to use 65000 (or something between 65000 and 65535) which are defined as being experimental and not for operation usage.  The examples would then be regenerated when the document is ready to progress or after you have actually received the correct assignment in the registry.   This is just good practice and the right way to do things.  You want to make sure that nobody implements and deploys before the registration is actually done.

Or

a7                                      # map(7)
   01                                   # unsigned(1)
   75                                   # text(21)