[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