Re: dane-openpgp 2nd LC resolution

E Taylor <hagfish@hagfish.name> Tue, 08 March 2016 02:16 UTC

Return-Path: <hagfish@hagfish.name>
X-Original-To: ietf@ietfc.amsl.com
Delivered-To: ietf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D22491CD8BF for <ietf@ietfc.amsl.com>; Mon, 7 Mar 2016 18:16:25 -0800 (PST)
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, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqWT8VMDsKML for <ietf@ietfc.amsl.com>; Mon, 7 Mar 2016 18:16:24 -0800 (PST)
Received: from gradienthosting.co.uk (gradienthosting.co.uk [159.253.56.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 4BE771CD664 for <ietf@ietf.org>; Mon, 7 Mar 2016 18:16:23 -0800 (PST)
Received: from enoch.localdomain (host109-149-4-243.range109-149.btcentralplus.com [::ffff:109.149.4.243]) (AUTH: LOGIN hagfish, TLS: TLSv1/SSLv3,128bits,DHE-RSA-AES128-SHA) by gradienthosting.co.uk with ESMTPSA; Tue, 08 Mar 2016 02:16:20 +0000 id 000000000008005F.0000000056DE35F4.000006F4
Received: from localhost ([127.0.0.1]) by enoch.localdomain with esmtp (Exim 4.80) (envelope-from <hagfish@hagfish.name>) id 1ad7C8-0001FL-4y; Tue, 08 Mar 2016 02:16:20 +0000
Message-ID: <56DE35F4.6060207@hagfish.name>
Date: Tue, 08 Mar 2016 02:16:20 +0000
From: E Taylor <hagfish@hagfish.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: dane-openpgp 2nd LC resolution
References: <56DC484F.7010607@cs.tcd.ie>
In-Reply-To: <56DC484F.7010607@cs.tcd.ie>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/OaM-of6bF_-rgtFnNcaMakPucqI>
Cc: IETF-Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2016 02:16:26 -0000

Hi Stephen,

> The tl;dr version is: once a revision addresses the
> substantive issues raised as per below, taking into
> account reactions to this summary, and we have a chance to
> take a quick look at -08 (I'll extend the LC to the date
> of the -08 version plus one week), then if no new
> substantive issues arise, I think we have rough consensus
> to go forward with this experiment (and others to come)
> and let the IESG review the document.

Thanks for producing this summary and these suggestions, with specific
sections of text to be added, which gives a clear picture of what we're
discussing.  I was initially concerned that your additions, and the
general process of updating the drafts to reach consensus, might have
made the document become an unruly patchwork, but I took the time to
re-read it, in light of what you propose, and it actually holds together
remarkably well.

In particular, I think your judgement on the casing / i18n issue is
sound, and seeing it in the context of the whole document makes it feel
like the most technologically neutral and acceptable solution.  It puts
no undue burdens on the traditions and best practices of the DNS
community, nor on the email community.  As you say, more work in a
future Standards Track document can be done to extend the approach
specified in the draft, but "doing so is also not required to determine
the outcome of this experiment".

One thing I wanted to bring to wider attention, though, was an
observation I made in looking at RFC 4398 (which is referenced in
section 1.1 of the draft).  That RFC, Storing Certificates in the Domain
Name System (DNS), says:

>    OpenPGP signed keys (certificates) use a general character string
>    User ID.  However, it is recommended by OpenPGP that such names
>    include the RFC 2822 email address of the party, as in "Leslie
>    Example <Leslie@host.example>"e>".  If such a format is used, the CERT
>    ought to be under the standard translation of the email address into
>    a domain name, which would be leslie.host.example in this case.  If
>    no RFC 2822 name can be extracted from the string name, no specific
>    domain name is recommended.

(internal references removed).  This is interesting because not only
does it not consider a non-ASCII (or even give an example of a
non-alphabetic) local-part, but it also happily lower-cases the
local-part, "under the standard translation of the email address into a
domain name".

Admittedly this RFC is from 2006, and of course it is good that the IETF
is now thinking harder about non-ASCII use cases, but I think that the
fact that this RFC was accepted onto the Standards Track, with that
approach to email addresses, reinforces your point that the experiment
of dane-openpgp can safely go ahead while leaving some questions open
until further data has been accumulated from wider deployment of this
technology.

I look forward to the closing of the extended LC, and to reading the
IESG's review of the -08 draft.

Best regards,
Edwin