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 <christer.holmberg@xxxxxxxxxxxx>; gen-art@xxxxxxxx > Cc: draft-ietf-ace-cwt-proof-of-possession.all@xxxxxxxx; ietf@xxxxxxxx; ace@xxxxxxxx > 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 <noreply@xxxxxxxx<mailto:noreply@xxxxxxxx>> > Sent: Friday, October 4, 2019 10:44 AM > To: gen-art@xxxxxxxx<mailto:gen-art@xxxxxxxx> > Cc: draft-ietf-ace-cwt-proof-of-possession.all@xxxxxxxx<mailto:draft-ietf-ace-cwt-proof-of-possession.all@xxxxxxxx>; ietf@xxxxxxxx<mailto:ietf@xxxxxxxx>; ace@xxxxxxxx<mailto:ace@xxxxxxxx> > 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&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4ffc136d2e014bc995db08d748f27b79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637058078607739810&sdata=Lusqkbg276AKiI%2Fd5MNEMGYKLcP3y%2FfrHP5L1u6UqYw%3D&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
