On Wed, Mar 14, 2018 at 2:34 PM, Mike Jones <[email protected]> wrote:
> Hi Ekr. Thanks for the review comments. Responses are inline below, > prefixed by "Mike>"... > > -----Original Message----- > From: Eric Rescorla <[email protected]> > Sent: Wednesday, March 7, 2018 12:40 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: > (with COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-ace-cbor-web-token-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The claim values defined in this specification MUST NOT be prefixed > with any CBOR tag. For instance, while CBOR tag 1 (epoch-based date/ > time) could logically be prefixed to values of the "exp", "nbf", and > "iat" claims, this is unnecessary, since the representation of the > claim values is already specified by the claim definitions. Tagging > claim values would only take up extra space without adding > information. However, this does not prohibit future claim > definitions from requiring the use of CBOR tags for those specific > claims. > > Why do you need a MUST NOT here? This seems like not really an interop > requirement > > Mike> This requirement was added to simplify both producers and consumers > of these tokens, after a working group discussion. Not having to have code > to validate, parse and then throw away tags prefixing claims of known types > both makes representations smaller and requires less code. Since the tags > add no value for these claims, it seemed better to require that they be > omitted. > Thanks. Seems reasonable. ] > 4. Verify that the resulting COSE Header includes only parameters > and values whose syntax and semantics are both understood and > supported or that are specified as being ignored when not > understood. > > I'm surprised to find that this is not a generic 8152 processing rule. > Can you explain why this is necessary here? > > Mike> This intentionally parallels the same rule in JWT ( > https://tools.ietf.org/html/rfc7519#section-7.2, step 5). It's saying > that you have to validate that the parameters describing the parameters > describing the cryptographic operations performed. Sure. I don't think this is unreasonable, but why isn't a general rule for COSE messages rather than just CWT? -Ekr > > -- Mike > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
