Creating a key bearing no user ID

[John Clizbe]

MFPA wrote:
> On Monday 23 January 2012 at 3:04:45 PM,  Holger wrote:
>
>> Please simply accept that it's an issue for me as well as many others.
>> Harvesting is supereasy: full keydumps are readily available.

Yep, Full keydumps are readily available. http://www.keysigning.org/sks/

Yep, harvesting is is easy. Anyone with a journeyman knowledge of perl and can
Google a regexp to match mail email addresses can do it. While a case can be
made that harvesting does occur. Several friends believe it occurs as do I.
However, testing I did a few years ago found the amount of SPAM attributable to
a key on a keyserver was not significantly different from that received as just
random SPAM noise from an unused ISP account. I've seen no volume of SPAM since
then to challenge that conclusion. Sending a message to an email list such as
this will likely result in at least an order of magnitude more SPAM than that
attributable to the, IMO apocryphal, bogeyman of keyserver harvesting.

> It sounds like you value the flavour of privacy that could be afforded by a
scheme involving the use of hashes in UIDs to protect names and email addresses.
Such a scheme would (for example) allow somebody with one of your email
addresses to locate your key, but would not allow somebody to devine your names
or email addresses by inspecting your key. An extension would be required to
allow GnuPG to locate keys using both the hash and the plaintext string
simultaneously.

I wondered when this regular exercise in sadoequinecrophilia would appear. :-(

The same issues remain untouched just like the countless other times you've
brought up this idea. What are it specifications? Is there any support from the
IETF OpenPGP working group? Is there an implementation of your idea?

Endlessly and tirelessly repeating the same "Wouldn't it be nice if...," without
addressing the issues posed and the questions asked only marks one as a crank or
a bore. While we're at it, I'd like low-priced dark beer, a smart good-looking
gingerbear boyfriend, and, of course, whirled peas.

> Suggestions like this tend to get lambasted because they do not
> enhance security, and privacy appears to be seen as unimportant.

The ceaseless implication that those who do not agree with your ideas believe
that privacy is unimportant is insulting to those who actively work producing
code to enhance individual and corporate privacy. Just stop it.
Changes to security software that do not increase security are to be examined
under heightened scrutiny -- complicating the codebase allows errors to hide.

I don't presently support this idea because the questions I've asked about it
have yet to be answered. I'm skeptical that I'm ever going to get the details.
The idea may have merit -- but most of us have yet to see that merit. I as
others are unconvinced that this idea will work, the interoperability and user
impact questions remain unanswered.

-John

(Replies _ONLY_ to the list, please.)
--
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
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"