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

From: Kyle Rose <[email-masked]>
Date: Fri, 2 Mar 2018 13:16:19 -0500

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 2 Mar 2018 13:28:48 -0500

Thanks for your review, Kyle!

On Fri, Mar 2, 2018 at 1:16 PM, Kyle Rose <[email-masked]> wrote:
> considerations seem to cover the same ground as the respective slices of the
> corresponding JWT references: the COSE RFC 8152 covers issues of trust
> 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

---

From: Mike Jones <[email-masked]>
Date: Fri, 2 Mar 2018 18:47:59 +0000

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

				-- Mike

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

On Fri, Mar 2, 2018 at 1:16 PM, Kyle Rose <[email-masked]> wrote:
> 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

---

From: Mike Jones <[email-masked]>
Date: Tue, 6 Mar 2018 00:45:37 +0000

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 <[email-masked]>; Kyle Rose <[email-masked]>
Cc: IETF SecDir <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: RE: Secdir last call review of draft-ietf-ace-cbor-web-token-12

				-- Mike

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

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kyle Rose <[email-masked]>
Date: Mon, 5 Mar 2018 21:24:03 -0500

I just perused the relevant parts of the diff. LGTM.

Thanks,
Kyle

On Mon, Mar 5, 2018 at 7:45 PM, Mike Jones <[email-masked]>
wrote:

> 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.
>
> Cc: IETF SecDir <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]
> Cc: IETF SecDir <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]