From: Samuel Erdtman [mailto:sam...@erdtman.se] Sent: Sunday, May 14, 2017 3:40 AM To: Jim Schaad <i...@augustcellars.com> Cc: ace <Ace@ietf.org> Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token Hi Jim, Thanks for your review and comments, see some initial replies inline. On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> > wrote: Not ready to ship. * I find the text for NumericDate confusing and would suggest this is a cleaner wording. The "NumericDate" term has the same meaning, syntax and Processing rules as the "NumericDate" term defined in Section 2 of JWT [RFC7519], except that the CBOR numeric representation (Section 2.4.1 of [RC7049]) is used. The encoding is modified so that the leading tag (6.1 or 0xC1) MUST be omitted. <Note above text kills the direct need for section 5.> Could make sense, I created an issue in the issue tracker to look at this. * What is a "CWT NumericDate" ? Why is this not just a "NumericDate"? You should be consistent on how you are using this and the "StringOrURI" type identifier. Either use the CWT prefix or don't. Makes sense to me, created an issue in the issue tracker to address this. * s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/ Makes sense to me, created an issue in the issue tracker to address this. * The algorithm for doing nesting detection is a gross abuse of the content type parameter and can be far more easily done based on the already present tagging of the COSE object. Could you please explain a bit more, we are using the COSE tags but have made them optional if the application for example only uses one thyme then it would always know what to do and would not need to parse the tag saving a byte. [JLS] The concept is pretty easy to explain. If you are in a situation where the full description of the CWT – including nesting layering – is known from a profile, then there would be no need to have any COSE tags present on any layer of the CWT message. I would however highly discourage using this situation for anything but a single layer CWT such as one that is based on the COSE_Encrypt0 message without any inner layering. Doing otherwise is going to mean that libraries would be unable to automatically unwrap all of the layers on their own, but would need guidance on each layer as it was processed. In the current document in step 5 of section 7.2, there is an assumption that a COSE tag is going to exist in order to distinguish between the different types of COSE messages – I would not that these tags are not explicitly called for in section 7.1 – so the algorithm that I am going to suggest means that they are supposed to be present not implicit in any event. In section 7.2 in step 7 the algorithm becomes: If the payload starts with one the of COSE identification tags, then the message is recursive – go to step 1, wash rinse and repeat. * Break section 8 into multiple paragraphs that deal with different types of issues. Might be reasonable I have created an issue in the issue tracker so that the comment is not lost. * In section 8, the first sentence implies to me that you believe that COSE is more of a problem that breaking of cryptographic algorithms, trust of certificates/keys. Not sure what needs to be done, but better clarity may be a good idea. Added this to the previously mentioned issue to address this to since it is in the same section * I have not done any validation of the examples. You might want to have an example which uses the real for one of the time types. Sorry, but I don´t get it could you add some more context. [JLS] Use the value of “1444064944.5” for one of the time values. Although I doubt that less than second resolution is needed in almost any case, having an example where it is given is still a good idea. Jim Jim -----Original Message----- From: Ace [mailto:ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> ] On Behalf Of Kepeng Li Sent: Thursday, April 20, 2017 2:53 PM To: ace@ietf.org <mailto:ace@ietf.org> Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net> > Subject: [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 <mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org <mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
