Subject: Re: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 May 2017 17:25:26 +0200

Review of draft-ietf-ace-cbor-web-token-04.txt
Reviewer: Carsten Bormann
Review result: A few technical issues; could use an editorial round

This specification sets out to translate JWT (RFC 7519) from JSON to
the CBOR world.  As such, it is relatively straightforward, and there
are only a few technical decisions that need to be made.  Clearly,
this should go ahead quickly, as it is sorely needed.

# Major technical

T1: Most fundamentally, the spec inherits a fundamental problem from JWT:
Some entries in the CWT ("claims") are actual independent claims that
can indeed be ignored if not understood, and other entries shape the
meaning of the actual claims in the CWT.  E.g., an nbf entry isn't
really a "claim" at all, it is an implicit parameter to the real
claims in the CWT.  This is, of course, a property that CWT shares
with JWT, but we could use the opportunity of defining CWT to be a bit
more specific.  E.g., we could use negative labels for entries that
shape others and unsigned ones for entries that can be ignored.
(BTW, all labels defined here would be the former category.)

T2: The spec doesn't clearly say that entry labels MUST be unsigned
numbers.  It could simply say that, but this creates an X-Dash
problem: Since people who want to experiment with CWT need to invent
numbers, they will, and there will be squatting galore.  CBOR actually
provides a nice way to solve this problem: Allow text strings as claim
labels for experimentation, replacing the need for a provisional
registration for each experiment.  No "production" CWT should have a
text label, of course; this is extremely easy to check.

T3: Section 7.2 repeats the giant mistake that JWT and the whole of
JOSE are being accused of: It tells you whether the CWT is a valid
CWT, but doesn't tell you whether it actually fulfills the security
objectives that you had.  Maybe add this explicitly to the steps.

# Other technical

T4: There was a recent move away from using CBOR Tag 1 for timestamps.
That move is fine, but why "NOT RECOMMENDED" now instead of completely
ruling it out?  Less options, more interoperability,

T5: The range 1 to 65536 is a seriously weird range.  If we do allow
one value that requires a four-byte representation then why not go for
1..4294967295?

T6: The IANA considerations may want to have different rules for
"good" label values (< 24, < 256 in that order) than for hoi polloi
ones.

# Major editorial

E1: On the editorial side, the abstract starts out by claiming [sic]
that CWT "is a profile" of JWT.  There is a definition of "profile" in
play that is a bit different from what some people might expect: a CWT
is not a JWT.

E2: The text is weirdly obsessed about CBOR serialization details.  It
is really making statements about the data model level, but dives into
serialization immediately instead.  This reads like a JSON spec would
read that would repeatedly talk about "double-quote-delimited strings,
which backslash escaping" each time a string is needed.  That's not
the way JSON is used, and we shouldn't start doing this for CBOR
either.  Just about every case that talks about "major type" really
should talk about the data that is desired.

E3: The definition of NumericDate does not reflect the decision that
using CBOR Tag 1 here is NOT RECOMMENDED.

E4: For those people who aren't the fourth co-author, maybe it would
help to provide the CDDL (not yet taking in any of the suggestions
above):

    cwt = {
        ? iss,
        ? sub,
        ? aud,
        ? cti,
        ? exp,
        ? nbf,
        ? iat,
        * otherlabel => value
    }

    iss = (1: text)
    sub = (2: text)
    aud = (3: text)
    exp = (4: number) ; interpreted as with CBOR Tag 1
    nbf = (5: number) ; interpreted as with CBOR Tag 1
    iat = (6: number) ; interpreted as with CBOR Tag 1
    cti = (7: bytes)

    otherlabel = uint .ge 8
    value = any

(We could play a bit with CDDL regexp support to distinguish URIs from
the other strings, but I skipped this.)

# Nits

s/to indicate type/to indicate the type/
s/contributions the specification/contributions to the specification/

Unfortunately, I haven't systematically checked the examples yet.

Grüße, Carsten

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 14 May 2017 19:38:23 +0200

Hi Carsten,

Thanks for the review and comments. I have added some initial replies
inline.

> (BTW, all labels defined here would be the former category.)

This is an interesting idea. I have added a ticket too look into this.

> text label, of course; this is extremely easy to check.

This makes sense, I have created a ticket to look into this.

> objectives that you had.  Maybe add this explicitly to the steps.

Not sure I get what you mean, do you want an additional step that verifies
the value of the claims e.g. checking validity time of the token or are you
referring to something else?

> ruling it out?  Less options, more interoperability,

Agree it makes more sense to remove this recommendation and place a MUST
here. I have created an issue to address this. But it also goes in line
with one of Jim´s comments.

> one value that requires a four-byte representation then why not go for

Not sure why, I have created an issue to look into this.

> "good" label values (< 24, < 256 in that order) than for hoi polloi

Could make sense I have created an issue to look into this.

> play that is a bit different from what some people might expect: a CWT
You have a point, do you have suggestions for better choice of wording. I
looked at how COSE handle its relation to JOSE but there seem to be a wider
gap between COSE and JOSE than CWT and JWT.
How about saying that 'CWT is an adaptation of JWT to a more constrained
environment using CBOR'.

> should talk about the data that is desired.

Make sense to me, I have created an issue to address this.

> using CBOR Tag 1 here is NOT RECOMMENDED.

This goes in line with one of the comments from Jim and and your T4
comment, Issues has been added for both.

> the other strings, but I skipped this.)

Not sure how this makes things clearer, but that could be because I´m one
of the co-author. Could we get some other opinions here before we commit to
adding this.

> s/contributions the specification/contributions to the specification/

Thanks, an issue has been added to not miss this.

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