choosing an encryption target from a User ID

[Ingo Klöcker]

On Friday 25 September 2009, Daniel Kahn Gillmor wrote:
> On 09/25/2009 11:06 AM, David Shaw wrote:
> > What troubles me about this sort of behavior is that it is
> > genuinely good and helpful in some cases and baffling and
> > off-putting in others. For example, someone has two different Alice
> > keys in their keyring. Both keys have a single UID, which is signed
> > by Baker.  One of the Alices (call her Alice1) is also signed by
> > Charlie.  The other Alice (Alice2) is signed by Dan.  Alice2 is a
> > newer key than Alice1.
>
> just to be clear: these are two keys with User IDs corresponding to
> the same e-mail address, right?  And that person knows Baker, and
> Baker has verified them with the keyholder, so presumably they're
> held by the same person.
>
> > At the moment, the keyring contains Alice1, Alice2, and Baker.  We
> > have full trust in Charlie and Dan, but they are not currently
> > present in the keyring.
>
> How does the keyring holder indicate full trust in charlie and dan
> without them being present in the keyring?  Have they done some sort
> of weird gpg --import-trustdb operation without pulling in the key
> itself? Is this something people normally do?
>
> If the user is assigning trust to charlie and dan explicitly during
> the key imports you describe, does that make the change in key
> selection behavior less confusing?
>
> > I'm not against that behavior - it's reasonable and makes sense...
> > to someone who really understands the web of trust and OpenPGP.
>
> Your implication here is that it doesn't make sense to someone who
> doesn't understand the WoT and OpenPGP. i think you're correct,
> sadly. But i think that the current behavior also doesn't make sense
> to those same people; if you haven't thought about how to choose a
> key based on the user ID, the whole process doesn't make sense.  In
> that (admittedly confused) state, it's even more important that the
> tools make healthy choices.
>
> What's more, there are (unusual) use cases for the current behavior
> that result in confusion and dangerously bad security.  For example,
> Charlie imported Alice's key a few years ago, and he imported Bob's
> key more recently.  Charlie has certified both Alice and Bob's keys,
> so from his perspective they both have full calculated validity. 
> Charlie granted Alice marginal ownertrust, because he think she's
> pretty good at making reasonable certifications.
>
> Charlie conscientiously runs a "gpg --refresh" every so often, and 
> one day Alice adds some new User IDs to her key (one of which matches
> "Bob"'s User ID).  Every message Charlie now sends to Bob is going to
> be encrypted to this bad User ID.  Bob won't be able to read them. 
> Even worse: if Alice has the ability to tamper with the mail stream
> between Charlie and Bob, she can intercept the messages, decrypt
> them, and re-encrypt them to Bob.
>
> Even if Charlie hadn't granted Alice marginal ownertrust, after he
> updated her key, every time he tried to encrypt data to Bob, he'd get
> a big warning about using a key with a poorly-bound User ID.

This example is a good example why "hard-coding" what key to use for a 
which contact/recipient (e.g. in the address book of the MUA) isn't 
such a bad idea. Once Bob's key has been stored in my address book 
Alice won't be able to trick me into using her key instead of Bob's.


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/20090926/4df5ac3c/attachment.pgp>