Re: [Id-event] Benjamin Kaduk's Yes on draft-ietf-secevent-http-poll-11: (with COMMENT)

[Mike Jones <[e-mail]>]

Thanks for your review, Ben.  https://tools.ietf.org/html/draft-ietf-secevent-http-poll-12 is intended to address your comments.  Detailed replies are inline, prefixed by "Mike>".

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[e-mail]> 
Sent: Tuesday, June 16, 2020 6:00 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Yaron Sheffer <[e-mail]>; [e-mail]
Subject: Benjamin Kaduk's Yes on draft-ietf-secevent-http-poll-11: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-secevent-http-poll-11: Yes

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-secevent-http-poll/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Prompted by Mark Notthingham's comments, we should perhaps leave some breadcrumbs that -push has discussion of alternatives considered and rejected, though this is less important if that section is to be removed prior to publication as an RFC.

Mike> I added a parallel appendix in the Poll draft referencing the one in the Push draft.

It may be worth mentioning explicitly in Section 1 that one of the pieces of configuration metadata to be exchanged includes the authentication/authorization information for the Recipient, or to discuss Recipient authentication/authorization in Section 3 where server (i.e.,
Transmitter) authentication is covered.

Mike> I added this statement: "Likewise, the SET Transmitter may choose to validate the identity of the SET Recipient, perhaps using mutual TLS."

When we reference RFC 6125, we only mention the DNS-ID name type in Section
4.3 but not in Section 3.  As for -push, we don't necessarily need to mention it in both places, but it might be nice to be consistent or to remove some of the redundancy.

Mike> DNS-ID is now consistently referenced across both drafts.

Section 5

As for -push, I think both SET Issuers and Transmitters (not just one or the
other) should consider the ramifications of sharing a particular SET.  While it's true that (as the secdir reviewer of -push noted) when JWE is used the Issuer has sole knowledge/control, but in other cases the Issuer may not know the full recipient list.

Mike> Both are now called out.

				Thanks again,
				-- Mike