choosing an encryption target from a User ID

[Daniel Kahn Gillmor]

Thanks for the discussion, Ingo!  This is really useful to me, and i
appreciate the thought you've obviously put in here.

On 09/29/2009 04:32 PM, Ingo Klöcker wrote:
> She creates a new key, but Bob 
> continues to use the old key. Unless Bob automatically imports unknown 
> keys, he will notice that Alice now uses a different key because he 
> cannot verify her signature anymore. And if Bob uses the old key to 
> send an encrypted message to Alice, Alice will surely tell him what 
> happened. 

will she?  will Alice know how to resolve the problem?  If she sends Bob
her new key, and Bob imports it, that would be great.  They've already
had to do some work manually.  Let's say that Bob even takes the time to
properly certify Alice's new key.  You're now asking Bob to take an
*additional* step of "re-binding" the new Key ID to the User ID -- why
would he need to do that, when he's already certified the key?

> I agree, but I also disagree. I agree that it's preferable to save the 
> user from having to make a choice. But then again I disagree about 
> the "not have as much understanding of the problem space". People who 
> do not understand to a certain degree how the WoT works would be better 
> off using a centralized PKI. IMO this is a major weakness of the WoT.

if you're doing explicit, hard-coded keyID-to-UserID bindings, you're
not using the WoT.  You're using your bindings, perhaps with a smidgen
of the WoT to make sure that the key isn't totally invalid or revoked.

The way i'd like to see the WoT actually used is to get people to think
about two things which are well within the range of normal human activity:

 a) who can i identify?

 b) who can i rely on to identify others?

and then let reasonable, well-thought-out mechanisms draw the links for
the people automatically, without them having to think about it.

If the tools don't do the Right Thing by default, then we start to ask
users to think about a bunch of extra arcane ideas beyond a and b (ideas
that folks on this list have actually thought about in-depth).  Those
are tough to understand, and non-experts are justifiably confused by them.

This is why we need the tools to draw the right patterns by default, not
an argument to use hard-coded bindings or some centralized PKI that asks
the user to make none of these decisions at all.

> See above. I wonder how much of a real problem this is. How many people 
> have multiple valid keys bound to the same email addresses? What is the 
> use case for having multiple valid keys bound to the same addresses?

I agree that it's not currently a common situation.  here are the few
legitimate situations with multiple keys that i know of:

 * several people are going through key transitions right now, for the
same reasons that the defaults are changing in gpg.  These people often
have two keys for a period of time.

 * Some people also have old keys that they have accidentally lost
access to.  once that happens, it's too late.

But:

Malicious people can upload keys with arbitrary User IDs to public
keyservers; if a user fetches one of those from a search (perhaps to
check the validity of any attached signatures), it's still in their
keyring, possible before the valid key of the corresponding user.

If we say "it's not a common situation, so we won't worry about extra
hassle; only a few people will have to deal with the hassle", but anyone
can inject material into the public keyservers that trigger the hassle
for anyone else, i think that's a problem, even if no one has chosen to
exploit it yet that we know of.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090929/ae20f114/attachment-0001.pgp>