[Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token
In Chicago, it was decided that we were going to WGLC the ACE CBOR Web Token draft. So this starts a working group last call for draft-ietf-ace-cbor-web-token for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday, May 2, 2017. The specification is available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04 An HTML-formatted version is also available at: http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html Thanks, Kind Regards Kepeng & Hannes ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token
Hello all, Kindly remind you to review the draft and provide your feedback today. Thanks, Kind Regards Kepeng 在 21/04/2017, 9:52 AM， "Ace on behalf of Kepeng Li" 写入: >In Chicago, it was decided that we were going to WGLC the ACE CBOR Web >Token draft. > >So this starts a working group last call for draft-ietf-ace-cbor-web-token >for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday, >May 2, 2017. > >The specification is available at: >https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04 > >An HTML-formatted version is also available at: >http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html > >Thanks, > > >Kind Regards >Kepeng & Hannes > > >___ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token
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
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token
Hi Carsten,
Thanks for the review and comments. I have added some initial replies
inline.
On Tue, May 2, 2017 at 5:25 PM, Carsten Bormann wrote:
> 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.)
>
This is an interesting idea. I have added a ticket too look into this.
>
> 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.
>
This makes sense, I have created a ticket to look into this.
>
> 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.
>
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?
>
>
> # 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,
>
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.
>
> 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?
>
Not sure why, I have created an issue to look into this.
>
> T6: The IANA considerations may want to have different rules for
> "good" label values (< 24, < 256 in that order) than for hoi polloi
> ones.
>
Could make sense I have created an issue to look into this.
>
> # 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.
>
>
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'.
> 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.
>
Make sense to me, I have created an issue to address this.
>
> E3: The definition of NumericDate does not reflect the decision that
> 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.
>
> 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 => val
