Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

From: Christer Holmberg via Datatracker <[email-masked]>
Date: Fri, 04 Oct 2019 10:44:17 -0700

Reviewer: Christer Holmberg
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-cwt-proof-of-possession-08
Reviewer: Christer Holmberg
Review Date: 2019-10-04
IETF LC End Date: 2019-10-09
IESG Telechat date: Not scheduled for a telechat

Summary: For most part the document is ready, but I have a few editorial
comments and an issue.

Major issues: N/A

Minor issues:

The text says in the Security Considerations that one must ensure that the
might not understand the "cnf" claim, and that applications must ensure that
receivers support it.

Q1: How are you going to ensure that, and why do you have to ensure that? RFC
8392 doesn't even seem to require that one must ensure that the receivers
support CWT.

Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims
must be discarded. If that can't be applied for "cnf" I think you need to
explain why.

Nits/editorial comments:

Q_ED_1: Please use [RFC8392] instead of [CWT] when referencing to RFC 8392.

Q_ED_2: Shall CBOR be enhanced on first occurrence (in the Abstract or
Introduction), or is it on the list of well-known abbreviations?

Q_ED_3: Add a reference for CBOR map on first occurrence.

(I was looking in RFC 7049, and while it mentions maps in many places I could
not find a proper definition for "CBOR map")

---

From: Mike Jones <[email-masked]>
Date: Wed, 16 Oct 2019 19:39:42 +0000

Thanks for your review, Christer.  Replies are inline, prefixed by "Mike>"…

-----Original Message-----
From: Christer Holmberg via Datatracker <[email-masked]>
Sent: Friday, October 4, 2019 10:44 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C4ffc136d2e014bc995db08d748f27b79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637058078607739810&amp;sdata=Lusqkbg276AKiI%2Fd5MNEMGYKLcP3y%2FfrHP5L1u6UqYw%3D&amp;reserved=0>.

Review Date: 2019-10-04

Summary: For most part the document is ready, but I have a few editorial comments and an issue.

Major issues: N/A

Minor issues:

The text says in the Security Considerations that one must ensure that the might not understand the "cnf" claim, and that applications must ensure that receivers support it.

8392 doesn't even seem to require that one must ensure that the receivers support CWT.

Mike> I agree that this text isn't actually actionable.  I propose that we simply delete it.

Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims must be discarded. If that can't be applied for "cnf" I think you need to explain why.

Mike> The RFC 8392 requirement does apply.  This is also aligned with the text in 3.1, so I don't think there are any changes needed to the spec for this.

Nits/editorial comments:

Mike> OK – will do.

Q_ED_2: Shall CBOR be enhanced on first occurrence (in the Abstract or Introduction), or is it on the list of well-known abbreviations?

Mike> I’d be glad to expand it to enhance readability.

(I was looking in RFC 7049, and while it mentions maps in many places I could not find a proper definition for "CBOR map")

Mike> Sure.  I can add a reference to Section 2.1 of RFC 7049.

---

From: Mike Jones <[email-masked]>
Date: Fri, 18 Oct 2019 22:57:06 +0000

Hi Christer,

https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has been published, which addresses your review comments in the ways proposed below.  Thanks again for your review!

                                                       -- Mike

From: Mike Jones
Sent: Wednesday, October 16, 2019 12:40 PM
To: Christer Holmberg <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

-----Original Message-----
From: Christer Holmberg via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 4, 2019 10:44 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

Review Date: 2019-10-04

Major issues: N/A

Minor issues:

Nits/editorial comments:

Mike> OK – will do.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Oct 2019 14:56:44 -0700

Thanks for the update, Mike.

I will go ahead and get this in front of the whole IESG, but one comment
below...

> Mike> The RFC 8392 requirement does apply.  This is also aligned with the text in 3.1, so I don't think there are any changes needed to the spec for this.

I don't think there's anything else we can reasonably do/say here, but it
does seem potentially surprising that we could get into a state where
client and AS both think that the token is a PoP token but the RS
interprets it as a bearer token.  I expect that in most cases where PoP
CWTs are used in an application context, either the client would be able to
detect this (e.g., by the RS not asking for a confirmation message) or the
client would send a confirmation message and the RS would treat it as
malformed, so the scope for practical impact seems limited, but it's hard
to confidently make sweeping statements.

-Ben