Re: [Ace] Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Wed, Mar 14, 2018 at 2:34 PM, Mike Jones <[e-mail]>
wrote:

> Hi Ekr.  Thanks for the review comments.  Responses are inline below,
> prefixed by "Mike>"...
>
> -----Original Message-----
> From: Eric Rescorla <[e-mail]>
> Sent: Wednesday, March 7, 2018 12:40 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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
>
>