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

[Kathleen Moriarty]

Thank you.

Sent from my mobile device

> On Mar 14, 2018, at 6:31 PM, Eric Rescorla  wrote:
> 
> Thanks. I have no objection to this draft proceeding as-si
> 
>> On Wed, Mar 14, 2018 at 2:55 PM, Mike Jones  
>> wrote:
>> Thanks, Ekr.  One more reply to your last comment the bottom of the message…
>> 
>>  
>> 
>> From: Eric Rescorla  
>> Sent: Wednesday, March 14, 2018 2:38 PM
>> To: Mike Jones 
>> Cc: The IESG ; kathleen.moriarty.i...@gmail.com; 
>> draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ka...@mit.edu; 
>> ace@ietf.org
>> 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  
>> wrote:
>> 
>> Hi Ekr.  Thanks for the review comments.  Responses are inline below, 
>> prefixed by "Mike>"...
>> 
>> 
>> -Original Message-
>> From: Eric Rescorla 
>> Sent: Wednesday, March 7, 2018 12:40 PM
>> To: The IESG 
>> Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; 
>> ka...@mit.edu; ace@ietf.org
>> 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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Eric Rescorla]

Thanks. I have no objection to this draft proceeding as-si

On Wed, Mar 14, 2018 at 2:55 PM, Mike Jones 
wrote:

> Thanks, Ekr.  One more reply to your last comment the bottom of the
> message…
>
>
>
> *From:* Eric Rescorla 
> *Sent:* Wednesday, March 14, 2018 2:38 PM
> *To:* Mike Jones 
> *Cc:* The IESG ; kathleen.moriarty.i...@gmail.com;
> draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ka...@mit.edu;
> ace@ietf.org
> *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 
> wrote:
>
> Hi Ekr.  Thanks for the review comments.  Responses are inline below,
> prefixed by "Mike>"...
>
>
> -Original Message-
> From: Eric Rescorla 
> Sent: Wednesday, March 7, 2018 12:40 PM
> To: The IESG 
> Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org;
> ka...@mit.edu; ace@ietf.org
> 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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Mike Jones]

Thanks, Ekr.  One more reply to your last comment the bottom of the message…

From: Eric Rescorla 
Sent: Wednesday, March 14, 2018 2:38 PM
To: Mike Jones 
Cc: The IESG ; kathleen.moriarty.i...@gmail.com; 
draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ka...@mit.edu; 
ace@ietf.org
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 
> wrote:
Hi Ekr.  Thanks for the review comments.  Responses are inline below, prefixed 
by "Mike>"...

-Original Message-
From: Eric Rescorla >
Sent: Wednesday, March 7, 2018 12:40 PM
To: The IESG >
Cc: 
draft-ietf-ace-cbor-web-to...@ietf.org;
 ace-cha...@ietf.org; 
ka...@mit.edu; ace@ietf.org
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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Eric Rescorla]

On Wed, Mar 14, 2018 at 2:34 PM, Mike Jones 
wrote:

> Hi Ekr.  Thanks for the review comments.  Responses are inline below,
> prefixed by "Mike>"...
>
> -Original Message-
> From: Eric Rescorla 
> Sent: Wednesday, March 7, 2018 12:40 PM
> To: The IESG 
> Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org;
> ka...@mit.edu; ace@ietf.org
> 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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Mike Jones]

Hi Ekr.  Thanks for the review comments.  Responses are inline below, prefixed 
by "Mike>"...

-Original Message-
From: Eric Rescorla  
Sent: Wednesday, March 7, 2018 12:40 PM
To: The IESG 
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org; ka...@mit.edu; 
ace@ietf.org
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.

  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.

-- Mike

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Kathleen Moriarty]

Hi Mike and authors,

Could you please respond to see if we can wrap this up?

Thanks,
Kathleen

On Wed, Mar 7, 2018 at 3:40 PM, Eric Rescorla  wrote:
> 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
>
>
>   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?
>
>



-- 

Best regards,
Kathleen

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-coap-est-00

[peter van der Stok]

>> * Should probably add a note in section 6 that any proxy that 
terminates

>> the
>> DTLS connection is going to be required to act as an RA.  RAs
are required
>> to have the entire request for adding authentication as 
necessary.


> This is visible in the figure of section 6, but needs elaboration 
in the

> text.

I don't understand why we have that paragraph.
An end point that terminates the Pledge (D)TLS connection and acts as
an RA *IS* a Join Registrar, not a Proxy.



Thus is outside the BRSKI context, and thus a proxy with RA (separate or 
not)


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace