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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]