Re: Last Call: <draft-ietf-dane-openpgpkey-05.txt>

E Taylor <hagfish@hagfish.name> Sat, 29 August 2015 00:16 UTC

Message-ID: <55E0F9F5.5020801@hagfish.name>
Date: Sat, 29 Aug 2015 01:16:53 +0100
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-05.txt>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/5uuauzlKTL_OJenfOHXHElF2Ia8>
Precedence: list

Hello,

The -05 draft looks good to me, but I've found a couple of typos /
consistency issues, and I have one recommendation for a functional
change.  This latter issue is one that has been discussed before, but I
wanted to make the point from my perspective here:

I think that, in practice, software that makes OPENPGPKEY lookups is
going to:
* check if the lookup fails, then
* detect if the email address being looked up contains any
capitalisations, and if so
* check if the lowercase version of the email address has an OPENPGPKEY
record available.
If it does find a record for the lowercase version in this situation,
the software's interface is going to prompt the user to ask if they are
happy to accept the lowercase version instead.  For non-interactive
lookups, I imagine there will be a config option (perhaps defaulting to
false or an empty list of domains) which determines whether the software
does this obvious best-effort lookup rather than failing.

Therefore my recommendation is that the draft add language saying that
implementers MAY attempt to look up the lowercase version of an email
address if the value entered by the user fails, but use it only if the
user has made some explicit confirmation that this is a reasonable thing
to do.  Mandating that software do something less useful, against the
user's wishes, in all circumstances, seems like too much to ask.

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"

* Section 7.3
"Applications that do not have users associated with, such as daemon
processes"
"Applications that do not have users associated with them, such as
daemon processes"

* Section 7.4
"Web of Trust"
"Web Of Trust" to match sections 1, 2.1.1 and 2.1.2 (or update those
sections to match section 7.4).

Best regards,
Edwin Taylor

Re: Last Call: <draft-ietf-dane-openpgpkey-05.txt> E Taylor