key question
John Clizbe
John at Mozilla-Enigmail.org
Sun Feb 28 00:09:08 CET 2010
This may be a dup - I think the original went out with the wrong From addr
MFPA wrote:
> Hi
> On Saturday 27 February 2010 at 6:11:29 AM, in
> <mid:4B88B791.7000100 at sixdemonbag.org>, Robert J. Hansen wrote:
>>> In any case, I've never seen a convincing argument *for* including email
>>> addresses in the UID of a PGP key.
Nor have we seen compelling arguments for their omission as a general rule
>> First, the status quo doesn't need arguments in its favor. The status quo
>> exists. *Changing* the status quo is what requires arguments in its
>> favor.
>
> I have always been taught to challenge the status quo. "Because that's the
> way we do it" is *never* a good reason to continue doing something in a
> particular way.
It is never a good reason when it is the sole justification. It's a perfectly
valid reason when it has evolved from the ideas of a lot of Very Smart People™.
> I understand that showing your email address in the UID makes it easier for
> people to find your key, the perceived advantage being that this makes it
> more likely you will receive encrypted mail. My contention is that the de
> facto standard of revealing email addresses in key UIDs could actually be
> mitigating *against* the use of encrypted mail, by discouraging people from
> publishing keys or even from using openPGP in the first place.
An /interesting/ thesis, However, to be taken seriously you need to back it up
with more than conjecture. There are plenty of obstacles to the widespread use
of encryption in the computing literature without grasping at straws to create more.
> There is a widespread perception (rightly or wrongly) that exposing your
> email address publicly on the internet will lead to that email address being
> spammed into oblivion. The new openPGP user is exhorted to create a key pair
> using their name and email address as the UID, and to upload this key to a
> server. That advice, coupled with the default configuration's enforcement of
> including an email address (or something that appears to be one) clearly has
> the potential to scare potential users from experimenting with openPGP in the
> first place.
Widespread perception? Indeed? Please quantify. There are over 2.8 million keys
on the SKS keyservers with an average of just under 350 new keys added every
day.[0] The "keyserver SPAM" discussion surfaces maybe three to four times per
year across three lists. Odds on users will get more SPAM from asking a question
on a public mailing list such as this one than they will from that attributable
to keyservers.
"(rightly or wrongly)" Or imaginary? Rather than trying to convince us of new
"obstacles" without providing any evidence, you may wish to review what the HCI
folks say are the obstacles: "Why Johnny Can't Encrypt"[1], "Why Johnny Still
Can't Encrypt"[2], "How to Make Secure Email Easier to Use"[3], and a personal
favorite, "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted
E-Mail"[4].
<snip>
>>> If their key lived at their own website or on an email responder, for
>>> example, you could still do this - except the note of the fingerprint and
>>> key-id would also need to contain a URL.
>
>> In which case you're still hosting it publicly, so why not use the
>> keyservers?
>
> Because by hosting it yourself, you have control over what signatures and
> UIDs appear on the published key. Or is that just an illusion?
Mostly Illusion. You only control the copy you publish or make available. You
have control over what signatures appear /until/ someone else has a copy of the
key. After that, you rely on their manners and ability to not make mistakes.
>>> OK OK, the post I was replying to when I started this stated "It is also
>>> a good idea to send your key to the keyservers." I do not see this
>>> statement as any kind of self-evident truth, yet I have been thoroughly
>>> taken to task for questioning it.
>
>> This is not "taking you to task." This is listening to your claims, and
>> giving strong arguments against them.
>
> Many of the replies I've read in this thread have that character. Others have
> tended more towards criticising me for holding a different opinion and/or
> dismissing anything I said. Maybe I'm just being over-sensitive, but I got
> the impression I had touched some raw nerves somewhere along the way.
Many of the points you argue in this thread have been exhaustively discussed on
the list. You could compare this to a novel reading of law taking on a mountain
of precedent. It takes more than just the presentation of a case to convince
this body.
I've seen errant ideas criticized, not any person. The only irritant for me was
a breach of email etiquette.
>> That said, it is broadly true that it's a good idea to send keys to the
>> keyserver network. The reasons why have already been well-explained. Your
>> reasons why not are either unfounded or debunked.
>
> The collective response on this thread has indeed debunked a few myths for
> me. The main issue I'll never be converted on is the potential privacy
> problem of publishing somebody else's key to the servers.
I think most of us agree that the publishing of another person's key(s) is
mostly attributable to a) accident, or b) ignorance. I don't think malice
normally is a factor.
<snip>
>> You've talked about spam
>
> Spam was one of my initial concerns, so I created a key containing my name
> and a real email address that I actually do use. That key has sat at
> BigLumber for over 5 years and on the keyservers for about three years. That
> address generally attracts 2-3 spam messages a month. The only messages
> encrypted to that key have been when I requested Login tokens from
> BigLumber.
This is partly due to the fact that it is more difficult to mine addresses from
BigLumber. But you are only a factor of 4 or 5 away from what I measured due to
keyserver SPAM five years ago.
>> The status quo is, "it is generally a good idea to send your key to the
>> keyserver network."
>
> That is a very different statement to the one you made a few lines up;
> changing "keys" to "your key" resolves the privacy problem of exposing other
> people's contact details.
The original statement I made that started this entire discussion was, "> It is
also a good idea to send your key to the keyservers."
>> If you want to change that, the burden is on you to present persuasive
>> evidence supporting a change. So far I've not seen it, which means the
>> status quo stands.
>
> I think that rather than just bald exhortation to use the keyservers, people
> could usefully be pointed to a discussion of the pros and cons so that they
> can make an informed choice. I would also welcome an end to the presumption
> that people will want to include their email address in their UID.
IIRC, we do this in the Enigmail Handbook[5]. But I've been distracted with
family issues as of late.
"Bald exhortation"? Honestly? You paint it as much more vociferous language than
it was. The pros and cons have been discussed, on this list, on the Enigmail
list, on PGP-Basics, probably on PGPNet but I don't subscribe. (I guess I could
ask a friend who's a member if I was curious enough.)
-John
[0] http://keyserver.gingerbear.net:11371/pks/lookup?op=stats
[1] http://gaudior.net/alma/johnny.pdf
[2] http://www.chariotsfire.com/pub/sheng-poster_abstract.pdf
[3] http://groups.csail.mit.edu/uid/projects/secure-email/chi_smime.pdf
[4] http://www.soe.ucsc.edu/classes/cmps223/Spring09/Gaw%2006.pdf
[5] http://enigmail.mozdev.org/documentation/handbook.php
--
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. 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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100227/0e612430/attachment.pgp>
More information about the Gnupg-users
mailing list