Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml

"John Levine" <johnl@taugh.com> Sun, 21 August 2016 17:52 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC42612D0B3 for <dispatch@ietfa.amsl.com>; Sun, 21 Aug 2016 10:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 4AoTLg7RM2t0 for <dispatch@ietfa.amsl.com>; Sun, 21 Aug 2016 10:52:09 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8156812D0B1 for <dispatch@ietf.org>; Sun, 21 Aug 2016 10:52:09 -0700 (PDT)
Received: (qmail 73234 invoked from network); 21 Aug 2016 17:52:07 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Aug 2016 17:52:07 -0000
Date: Sun, 21 Aug 2016 17:51:45 -0000
Message-ID: <20160821175145.26541.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: dispatch@ietf.org
In-Reply-To: <CABcZeBOvc0pO9=+SM3P5cc3JPs9i9O3Peaf2wwKbLGoQQvpsvA@mail.gmail.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/4oPVg6BS70WEaTOVv-58Wrh4KMI>
Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Aug 2016 17:52:11 -0000

>Yeah, that seems like it might be OK in some sort of informational document
>describing common practice, but this document is asking for Standards
>Track, and in that situation it seems like actually specifying one class of
>behavior is the superior direction.

Sure, if that were feasible.  I see no chance at all of getting a
sufficient agreement that domains are authorititative, or that they
aren't.  From what I've seen so far, few people have even thought
about it, and fewer still outside the context of whatever mail system
they personally are running.  People at gmail said they're interested
in this, so I can ask if they've thought about it in the context of
a very large public mail system.

>> Good point, MUST for https seems obvious.
>
>I don't just mean MUST for HTTP, but also encouraging the use of valid
>certs.

OK.

>> Again, this is out of RFC 4387.  I was under the impression that the
>> client could look at the certs and see what chained to what.
>
>The text in 4387 is not maximally clear. It appears that perhaps the idea
>is that this is just EE certs. If it's a mix of multiple EE and chain
>certs, it's not reasonable to expect the RP to make sense of it. In any
>case, this text should be clear.

I am not a great pkix expert, so pointers and suggestions are welcone.

R's,
John