Thanks for clarifications Jim, see my comments inline. Mike, there is a question for you inlined too.
On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <i...@augustcellars.com> wrote: > > > > > *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> > 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. > I think I see your point. In the case of nested CWTs you would like to mandate the inner layer to have a COSE tag indicating the message type. But in cases where e.g. transport is done over CoAP you don´t feel it is as important. I personally would like to go all the way and mandate the COSE tag for all CWT messages nested or not but that would add some extra bytes i.e. not good in all cases. Maybe a compromise and mandate it for inner object in nested CWTs. @Mike would you like to comment to before we decide on a path forward. > > > > * 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. > > Makes sense, as you say it might not be a core case but there should be at least one example of it if we support it. I have created a ticket to address it. > > > Jim > > > > > > > > > Jim > > > > -----Original Message----- > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Kepeng Li > Sent: Thursday, April 20, 2017 2:53 PM > To: ace@ietf.org > Cc: Hannes Tschofenig <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 > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > 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
