choosing an encryption target from a User ID

[Ingo Klöcker]

On Wednesday 30 September 2009, Daniel Kahn Gillmor wrote:
> Thanks for the discussion, Ingo!  This is really useful to me, and i
> appreciate the thought you've obviously put in here.

Thank you, the same to you! You really make me thinking.


> 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?

True, but this could be solved by improving the used tools. People using 
KMail and OpenPGP will probably use KGpg for key management. So it 
would probably make sense to make KGpg aware of the "key-bindings" 
(which are stored in the KDE-wide address book btw, so this isn't 
strictly KMail-specific) and ask Bob after he certified Alice key. Just 
an idea.


> > 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?

I have no problem doing this.


>  b) who can i rely on to identify others?

This is what is giving me major headaches. Maybe I'm too pessimistic or 
paranoid, but I trust almost nobody. I prefer to go to keysigning 
parties and check the ids myself. You are correct, that this is not 
what the WoT is about.


> 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.

I see the value in tools doing the Right Thing by default, so I agree 
that gpg should probably be improved in this respect. Maybe I'm really 
doing something wrong. Maybe you are right in that I should stick to 
what gpg thinks is best and only use hard-coded bindings if it's really 
necessary. Hmm. I need to think about this.


> > 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.

Yes. That's a good use case.


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

Yeah. That's basically a variation of the above use case.


> 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.

Hmm, AFAIU, for someone who does not blindly certify such keys this 
shouldn't be a problem since those malicious keys wouldn't be valid and 
thus wouldn't take preference over a valid key ... unless somebody else 
this person trusts is trying to screw them.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20090930/2dde817e/attachment.pgp>