Thank you.

Sent from my mobile device

> On Mar 14, 2018, at 6:31 PM, Eric Rescorla <[email protected]> wrote:
> 
> Thanks. I have no objection to this draft proceeding as-si
> 
>> On Wed, Mar 14, 2018 at 2:55 PM, Mike Jones <[email protected]> 
>> wrote:
>> Thanks, Ekr.  One more reply to your last comment the bottom of the message…
>> 
>>  
>> 
>> From: Eric Rescorla <[email protected]> 
>> Sent: Wednesday, March 14, 2018 2:38 PM
>> To: Mike Jones <[email protected]>
>> Cc: The IESG <[email protected]>; [email protected]; 
>> [email protected]; [email protected]; [email protected]; 
>> [email protected]
>> Subject: Re: Eric Rescorla's No Objection on 
>> draft-ietf-ace-cbor-web-token-13: (with COMMENT)
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> 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?
>> 
>>  
>> 
>> Mike> I’m sure that COSE has similar/overlapping requirements (that, or I 
>> didn’t adequately review it at the time before it became an RFC ;-) ).  As 
>> the Brits, say, this rule is “belt and suspenders” on top of that – and also 
>> reflects that CWT copies the syntax and semantics from JWT [RFC 7519] 
>> wherever applicable.
>> 
>>  
>> 
>> See you next week.
>> 
>>  
>> 
>>                                                        -- Mike
>> 
>>  
>> 
>> -Ekr
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> 
>>                                 -- Mike
>> 
>>  
>> 
> 
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

Reply via email to