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

[Eric Rescorla]

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?


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

Re: [Ace] [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Alissa Cooper]

Dan, thanks for your review. Mike et al, thanks for your responses. I 
appreciate the novelty of the registration process here but I think the text as 
it currently stands is clear enough. I entered a No Objection ballot.

Alissa


> On Mar 5, 2018, at 7:44 PM, Mike Jones  wrote:
> 
> Dan, you’ll find changes that address your review comments in 
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13 
> .  See 
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13#appendix-C 
>  for 
> a summary of the changes made.
>  
> Thanks again for your useful review!
>  
>   -- Mike
>  
> From: Dan Romascanu > 
> Sent: Tuesday, February 27, 2018 11:24 PM
> To: Mike Jones  >
> Cc: Jim Schaad >; 
> gen-art >; ace@ietf.org 
> ; ietf >; Benjamin 
> Kaduk >; 
> draft-ietf-ace-cbor-web-token@ietf.org 
> 
> Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12
>  
> Hi Mike,
> 
> The edits that you propose in #1 and #2 are good IMO and they would improve 
> the clarity of the document.
> 
> Concerning #3 - all the 'running code' examples that you provided are all for 
> one type of policy only - Specification Required. The case here seems a 
> little more complex, as the review and required advice refer to multiple 
> policies. Thanks to the discussion and information provided by you and Jim, I 
> believe that I better understand now how this works, and I defer to the 
> General Area and Security AD the decision whether the text is sufficiently 
> clear.
> 
> Thanks for addressing my comments.
> 
> Regards,
> 
> Dan
> 
>  
> On Wed, Feb 28, 2018 at 12:52 AM, Mike Jones  > wrote:
> Replies inline…
>  
> From: Ace > On Behalf Of 
> Dan Romascanu
> Sent: Tuesday, February 27, 2018 2:23 PM
> To: Jim Schaad >
> Cc: gen-art >; ace@ietf.org 
> ; ietf >; Benjamin 
> Kaduk >; 
> draft-ietf-ace-cbor-web-token@ietf.org 
> 
> Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12
>  
> Hi Jim,
> 
> There are still a few problems: 
>  
> 1. The policies and mapping to the values ranges are hidden in the Claim Key 
> field in the template (the comment also made by Kathleen)
>  
> Per my earlier note, I will be making this language clearer when the next 
> revision is published.
>   
>
>  
> 2. At least one incorrect policy name is used: Standards Track Required - do 
> you mean Standards Action (?)
>  
> Thanks – I’ll update the terminology when the next draft is published.
>  
> 3. You describe a process that involves a mail list (cwt-reg-rev...@ietf.org 
> ) and Experts Review. This description is not 
> clear. Usually IANA approaches one DE for advice and expects the advice from 
> the same DE in a reasonable period of time. If I understand correctly the 
> process described in Section 9.1 one or more DEs make a recommendation and 
> run it with the mail list. Who establishes the consensus on the mail list? 
> Assuming the mail list disagrees with the DE recommendation, who decides?
>  
> This is the process used for the .well-known URI spec, the JSON Web Token 
> (JWT) spec, the JOSE specs, many OAuth specs and it works well.  It allows 
> interested parties to see and comment on registration requests.  The 
> Designated Experts are still the ones to decide.  See these references for 
> some uses of this kind of publicly-visible registration procedure:
>  
> https://tools.ietf.org/html/rfc5785#section-5.1 
>  (using 
> wellknown-uri-rev...@ietf.org )
> https://tools.ietf.org/html/rfc6749#section-11.1 
>  (using 
> oauth-ext-rev...@ietf.org )
> https://tools.ietf.org/html/rfc7515#section-9 
>  (using 
> jose-reg-rev...@ietf.org 

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

[Mike Jones]

Thanks, Ben and Adam.  I've recoded a note to address the improvements below 
one the submission tool reopens.

For what it's worth, I independently noticed the unintended overlap between the 
Standards Action and Specification Required number ranges in a conversation 
today with IANA.

The point of including new CWT definitions for "StringOrURI" and "NumericDate" 
was so that we could use them directly.  Prefixing them with "CWT" isn't 
necessary for the meaning to be clear in context.

Thanks both for the attention to detail.

-- Mike

-Original Message-
From: Benjamin Kaduk  
Sent: Wednesday, March 7, 2018 8:24 PM
To: Adam Roach 
Cc: The IESG ; draft-ietf-ace-cbor-web-to...@ietf.org; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: 
(with COMMENT)

Hi Adam,

With my shepherd hat...

On Wed, Mar 07, 2018 at 04:05:32PM -0800, Adam Roach wrote:
> 
> Thanks to the WG, chairs, and
> 
> §3.1.1:
> 
> >  The "iss" (issuer) claim has the same meaning and processing rules 
> > as  the "iss" claim defined in Section 4.1.1 of [RFC7519], except 
> > that  the value is of type StringOrURI.  The Claim Key 1 is used to  
> > identify this claim.
> 
> 
> 1) Given that RFC 7159 defines "iss" to contain a "StringOrURI" value, it's
>not clear what the "except" clause is attempting to convey.

I had to ask about this as well -- the crux is that the "StringOrURI" JWT type 
is different from the CWT "StringOrURI"
type.  IIRC there used to be an extra descriptor in here but it was removed as 
redundant.

> 2) Given the many uses of the word "type" in this context (including CBOR
>types and the JWT 'typ' field), and given that RFC 7519 never refers to
>"StringOrURI" as a "type," I think that the use of the word "type" here
>is likely to lead to reader confusion.

In combination with the above, maybe we want "the value is a CWT StringOrURI 
value".  Authors?

> This comment -- or a congruent form of it involving "NumericDate" 
> rather than "StringOrURI" -- applies to §3.1.2 through §3.1.6.

(Right.)

> --
> -
> 
> §9.1:
> 
> >  Criteria that should be applied by the Designated Experts includes  
> > determining whether the proposed registration duplicates existing  
> > functionality, whether it is likely to be of general applicability 
> > or  whether it is useful only for a single application, and whether 
> > the  registration description is clear.  Registrations for the 
> > limited set  of values between -256 and 255 and strings of length 1 
> > are to be  restricted to claims with general applicability.
> 
> Use of the word "between" without qualifying it as inclusive or 
> exclusive of the endpoints is ambiguous. Suggest either "values from 
> -256 to 255" or "values between -256 and 255 inclusive".

Agreed, it should be qualified as inclusive.

> --
> -
> 
> §9.1.1:
> 
> > CBOR map key for the claim.  Different ranges of values use
> > different registration policies [RFC8126].  Integer values between
> > -256 and 255 and strings of length 1 are designated as Standards
> > Action.  Integer values from -65536 to 65535 and strings of length
> > 2 are designated as Specification Required
> 
> Same comment as above.
> 
> Also, please replace "from -65536 to 65535" with "from -65536 to -257 
> and from
> 256 to 65535".

Good catch!

Thanks,

Ben

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

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

[Adam Roach]

On 3/7/18 11:47 PM, Mike Jones wrote:

The point of including new CWT definitions for "StringOrURI" and "NumericDate" was so 
that we could use them directly.  Prefixing them with "CWT" isn't necessary for the meaning to be 
clear in context.



Given that the current formulation confused both Benjamin and me, I 
think this assertion doesn't hold up to scrutiny.


/a

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

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

[Mike Jones]

Fair enough.  I'll work on alternate exposition for these types to avoid any 
potential confusion.

Thanks again,
-- Mike

-Original Message-
From: Adam Roach  
Sent: Wednesday, March 7, 2018 10:28 PM
To: Mike Jones ; Benjamin Kaduk 
Cc: The IESG ; draft-ietf-ace-cbor-web-to...@ietf.org; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: 
(with COMMENT)

On 3/7/18 11:47 PM, Mike Jones wrote:
> The point of including new CWT definitions for "StringOrURI" and 
> "NumericDate" was so that we could use them directly.  Prefixing them with 
> "CWT" isn't necessary for the meaning to be clear in context.


Given that the current formulation confused both Benjamin and me, I think this 
assertion doesn't hold up to scrutiny.

/a

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