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

Benjamin Kaduk <kaduk@mit.edu> Sat, 25 April 2020 00:43 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA693A1231; Fri, 24 Apr 2020 17:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2yYY25EYAHk; Fri, 24 Apr 2020 17:43:55 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980A13A122F; Fri, 24 Apr 2020 17:43:51 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03P0hlbr000717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Apr 2020 20:43:49 -0400
Date: Fri, 24 Apr 2020 17:43:46 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "draft-ietf-secevent-http-push.all@ietf.org" <draft-ietf-secevent-http-push.all@ietf.org>, "id-event@ietf.org" <id-event@ietf.org>
Message-ID: <20200425004346.GB27494@kduck.mit.edu>
References: <DM6PR00MB06820ACC4F7F25AE7042FB5AF51C0@DM6PR00MB0682.namprd00.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM6PR00MB06820ACC4F7F25AE7042FB5AF51C0@DM6PR00MB0682.namprd00.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/CHgetcfPRFLH1S251sAEwHdRi1I>
Subject: Re: [Id-event] AD review of draft-ietf-secevent-http-push-07
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Apr 2020 00:43:57 -0000

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 <id-event-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> Sent: Tuesday, December 10, 2019 4:36 PM
> To: draft-ietf-secevent-http-push.all@ietf.org
> Cc: id-event@ietf.org
> 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