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