Subject: Re: [Id-event] AD review of draft-ietf-secevent-http-push-07

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Apr 2020 17:43:46 -0700

Hi Mike,

My apologies for yet another long delay.  I'll trim the bits that are in
good shape (nearly all of them!).

I also took another look at the "diff" (manually, that is) between push and
poll, and found a few things in poll that should probably be here as well.

Section 1 should get the sentence "How SETs are defined and the process by
which security events are identified for SET Recipients are specified in
[RFC8417]."

In the thread for -poll we said that Section 5.3 of this document would get
a s/e.g., subject claims/PII/ to match, but that doesn't seem to have
happened yet.

The poll Privacy Considerations have a note at the start of the section
about "SET Transmistters SHOULD attempt to deliver sets that are targeted
to the specific business and protocol needs of subscribers"; would a
similar note make sense for us?

On Fri, Feb 07, 2020 at 05:17:12PM +0000, Mike Jones wrote:
> draft-ietf-secevent-http-push-08<https://tools.ietf.org/html/draft-ietf-secevent-http-push-08> was published to address these review comments.  (-09<https://tools.ietf.org/html/draft-ietf-secevent-http-push-09> addressed additional editorial nits.)  Descriptions of the changes made for these comments are inline, prefixed by "Mike>".
> 
> 
> 
> -----Original Message-----
> From: Id-event <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: Tuesday, December 10, 2019 4:36 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Id-event] AD review of draft-ietf-secevent-http-push-07
> 
> 
> Section 5
> 
> 
> 
> I want to see how the discussion goes on poll's "Access Token Considerations" first, but we may want something like that as well.
> 
> 
> 
> Mike> Yes, it makes sense to do that

Since we no longer explicitly mention WWW-Authenticate in this document I
won't insist on copying the Access Token Considerations over, but it could
still be useful to do so.

> Section 5.2
> 
> 
> 
> RFC 6125 is great and I'm glad we're referencing it, but it does leave a couple of gaps to be specified for a full picture of application usage.
> 
> Specifically, we should say what name from the certificate we validate (and, ideally, how the application knows what name it is expecting to see in that name field in the certificate).  Most applications these days will be using the DNS-ID, and perhaps something about wildcards and/or revocation info.  The last time I was making this comment on a document I pointed to RFC 8461 as a potential example to crib from, at least in terms of the types of things to talk about.
> 
> 
> 
> Mike> I added DNS-ID.

The DNS-ID is the part of the certificate that we compare a name against,
but a comparison requires having two things -- since recipients are already
configured, can't we say that the expected name will be configured as well?

Thanks for all the updates!

-Ben