Why hashed User IDs is not the solution to User ID enumeration (was: Re: Creating a key bearing no user ID)

[John Clizbe]

MFPA wrote:
> Hi
> On Tuesday 24 January 2012 at 3:21:35 PM, in Daniel Kahn Gillmor wrote:
>> Certainly, the keyservers will continue to support non-digested User IDs,
>> so now tools will need to be able to handle both of them; we'll also need a
>> policy for end-user agents to answer questions like "when looking up this
>> e-mail address, do i send it only in digested form to the keyservers for
>> lookup?

Dan, Enigmail's Per-recipient rules are a perfect way of matching email address
to a key without that email address in an UID or when when multiple keys contain
UIDs with the same email address.

> That would fail to return keys that had UIDs containing the non-hashed
> string, unless the keyservers stored hashes for all plaintext UIDs.

Huh? Why on Earth would hashes need to be stored for plaintext UIDs? Present day
keyservers don't even store the UID as a single element.

That's ridiculous. Perhaps an understanding of the workings of keyserver lookup
should be gained before trying to modify how OpenPGP UIDs are handled.

https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00

Other than the human element, I don't see a reason the keyserver code would need
to be changed. Most of my objections to this idea lie in matters of HCI.

-- 
John P. Clizbe                      Inet: John ( a ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"