Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
E Taylor <hagfish@hagfish.name> Sun, 14 February 2016 15:04 UTC
Return-Path: <hagfish@hagfish.name>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id DBFAC1ACDF3
for <ietf@ietfa.amsl.com>; Sun, 14 Feb 2016 07:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level:
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5
tests=[BAYES_50=0.8, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001]
autolearn=ham
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 Rd1hYOJLeNQN for <ietf@ietfa.amsl.com>;
Sun, 14 Feb 2016 07:04:07 -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 ietfa.amsl.com (Postfix) with ESMTPS id 86B231ACDDE
for <ietf@ietf.org>; Sun, 14 Feb 2016 07:04:07 -0800 (PST)
Received: from enoch.localdomain
(host86-152-126-106.range86-152.btcentralplus.com [::ffff:86.152.126.106])
(AUTH: LOGIN hagfish, TLS: TLSv1/SSLv3,128bits,DHE-RSA-AES128-SHA)
by gradienthosting.co.uk with ESMTPSA; Sun, 14 Feb 2016 15:04:05 +0000
id 0000000000080006.0000000056C09765.000035BD
Received: from localhost ([127.0.0.1])
by enoch.localdomain with esmtp (Exim 4.80)
(envelope-from <hagfish@hagfish.name>) id 1aUyDU-0004Tq-Jo
for ietf@ietf.org; Sun, 14 Feb 2016 15:04:04 +0000
Message-ID: <56C09764.1020700@hagfish.name>
Date: Sun, 14 Feb 2016 15:04:04 +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: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Lac50NDVxYxU12amG0dsFkbj2NM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 14 Feb 2016 15:04:10 -0000
Hello, For the record, I'd like to repeat some of the comments I made on the -05 draft, to clarify my position on the lowercasing issue (in light of recent deployment examples), and to list the few remaining typographical / consistency issues in the text of the document. On the topic of lowercasing, it seems that there are still differing opinions, and this is potentially reflected by the implementations that now exist. For example, the author has pointed out some examples of clients which force lowercasing, and I've checked that Mail.de (which supports adding OpenPGP key information to the DNS[0]) replaces uppercase letters with their lowercase equivalent when choosing a username at sign-up (so presumably store only an entry for the lowercase version in the DNS). The online tester at openpgpkey.info[1] (run by Mail.de) also forces email addresses to lowercase before searching. In contrast, Posteo.de has announced a "key search" feature[2] (as well as allowing its users to add their key information to the DNS[3]) but haven't mentioned lowercasing when searching (although I haven't confirmed that they don't). Also, the online DNS record generator at huque.com[4] is case sensitive and produces an error message if it detects a mismatch (even just on case) between the "PGP userid (email)" specified and the UIDs in the public key provided. My suggestion for a consensus, therefore, is that the draft recommend that clients attempt the case sensitive lookup first, and then fall back to a lowercase lookup if that fails (ideally informing the user that it has done this). For the rare situation where a user specifies an email address with uppercase characters in, this will result in an extra query, but in the rarer situation that the lowercase version doesn't exist (or represents a different user) then this provides a worthwhile security benefit. Moreover, I think that if the draft doesn't mention the possibility of lowercasing, then client implementers will either force lowercasing out of habit, or make their software search for both just to be sure, as I have outlined above. [0] https://mail.de/blog/2015-03-pgp-schluessel-ueber-mailde-dns-server-verbreiten/ [1] https://openpgpkey.info/ [2] https://posteo.de/en/blog/new-posteo-webmail-interface-can-find-public-keys [3] https://posteo.de/en/blog/new-posteo-public-key-directory [4] https://www.huque.com/bin/openpgpkey The more minor issues I list below: * Section 1 "using either the HTTP Keyserver Protocol [HKP] Alternatively, users" "using the HTTP Keyserver Protocol [HKP]. Alternatively, users" * Section 1 "Therefor, these keyservers are not well suited" "Therefore, these keyservers are not well suited" * Section 2.1.2 "to ensure that correspondents know about these earlier then expected revocations." "to ensure that correspondents know about these earlier than expected revocations." * Section 2.1.2 "Strip away all but the most recent self-sig for the remaining user IDs and subkeys" "Strip away all but the most recent self-signature for the remaining User IDs and subkeys." * Section 2.1.2 Missing "." at end of some bulleted sections. * Section 4 "A client supporting OPENPGPKEY therefor MUST NOT perform" "A client supporting OPENPGPKEY therefore MUST NOT perform" * Throughout "Web Of Trust" / "web of trust" "Web of Trust" (or whatever the preferred convention is) * Throughout "Behaviour" "Behavior" (if American English is required) Best regards, Edwin Taylor
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> E Taylor
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> E Taylor
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Harald Alvestrand
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Harald Alvestrand
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> ned+ietf
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Harald Alvestrand
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Keith Moore
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John R Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Stephen Farrell
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Stephen Farrell
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin