Re: [secdir] Secdir last call review of draft-ietf-ace-cbor-web-token-12

[Mike Jones <[e-mail]>]

Hi Kyle,

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

-----Original Message-----
From: Mike Jones 
Sent: Friday, March 2, 2018 10:48 AM
To: Kathleen Moriarty <[e-mail]>; Kyle Rose <[e-mail]>
Cc: IETF SecDir <[e-mail]>; The IESG <[e-mail]>; [e-mail]
Subject: RE: Secdir last call review of draft-ietf-ace-cbor-web-token-12

Thanks, Kyle.  I'll plan to update the document accordingly.

				-- Mike

-----Original Message-----
From: Kathleen Moriarty <[e-mail]>
Sent: Friday, March 2, 2018 10:29 AM
To: Kyle Rose <[e-mail]>
Cc: IETF SecDir <[e-mail]>; The IESG <[e-mail]>; [e-mail]
Subject: Re: Secdir last call review of draft-ietf-ace-cbor-web-token-12

Thanks for your review, Kyle!

On Fri, Mar 2, 2018 at 1:16 PM, Kyle Rose <[e-mail]> wrote:
> Reviewer: Kyle Rose
> Review result: Ready with nits
>
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
> This draft specifies a means for representing claims in CBOR, and for 
> using COSE to encrypt and authenticate such claims. The listed 
> security considerations seem to cover the same ground as the 
> respective slices of the corresponding JWT references: the COSE RFC
> 8152 covers issues of trust establishment, as well as the vagaries of 
> signature algorithms and key reuse, in more depth.
>
> My only nit for this document is the repeated use of the phrasing 
> "...has the same meaning, syntax, and processing rules as..."
> throughout section
> 3.1: specifically, the inclusion of "syntax". For example, it doesn't 
> seem to make sense to talk about the syntax of a CBOR NumericDate 
> being the same as, or different from, the syntax of a JSON
> NumericDate: clearly, the binary representation is different, and it's 
> not at all clear that it makes sense to talk about the human-readable 
> source representation in this context. That said, there is some 
> parallelism with respect to StringOrURI, as presumably the intent is 
> to require that all strings containing a colon also be valid URIs.
>

Good point.  Authors, please put these adjustments in your working copy of the draft and ack the changes made here.

Thank you,
Kathleen



-- 

Best regards,
Kathleen