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

[Benjamin Kaduk <[e-mail]>]

Thanks for the update, Mike.

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

On Fri, Oct 18, 2019 at 10:57:06PM +0000, Mike Jones wrote:
> 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 <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08
> 
> 
> Thanks for your review, Christer.  Replies are inline, prefixed by "Mike>"…
> 
> 
> 
> -----Original Message-----
> From: Christer Holmberg via Datatracker <[e-mail]<mailto:[e-mail]>>
> Sent: Friday, October 4, 2019 10:44 AM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08
> 
> 
> 
> 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://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>.
> 
> 
> 
> 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.
> 
> 
> 
> 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.

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