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

[Benjamin Kaduk <[e-mail]>]

On Mon, Apr 27, 2020 at 08:54:05PM +0000, Richard Backman, Annabelle wrote:
> I can put out an update, but I think I'm missing part of the conversation here.
> 
> Here is what I understand the changes to be, all within -push:

I think that's right, as much as putting (3) out of scope pains me.

Thanks,

Ben

> 1. 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]."
> 
> 2. In Section 5.3, replace "e.g., subject claims" with "PII" as was already done in -poll.
> 
> 3. In Section 5.3, add text explaining that determining the expected service identity to match against using DNS-ID is out of scope.
> 
> 4. In Privacy Considerations, add "SET Transmistters SHOULD attempt to deliver sets that are targeted to the specific business and protocol needs of subscribers", as already exists within -poll.
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
>  
> 
> On 4/24/20, 7:12 PM, "Mike Jones" <[e-mail]> wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> These suggestions make sense to me.  Do you want to do these Annabelle, or would you like me to?  If I do it, it will probably be early next week.
> 
>                                 Thanks all,
>                                 -- Mike
> 
> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Friday, April 24, 2020 5:44 PM
> To: Mike Jones <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Id-event] AD review of draft-ietf-secevent-http-push-07
> 
> 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 <[e-mail]> On Behalf Of Benjamin Kaduk
> > Sent: Tuesday, December 10, 2019 4:36 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > 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
>