choosing an encryption target from a User ID

[Daniel Kahn Gillmor]

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.

> My problem is that there is the potential for a lot of confusion here. 
> Making the behavior optional doesn't really resolve that, as to be
> useful, you want this sort of key-picking behavior to be the default (I
> might even argue that if we do it, it shouldn't be something that could
> be switched off, as at least there would be only 1 confusing behavior to
> document, rather than two).

Yeah, i think this is reasonable.  I think the simple description of the
behavior is:

  Any time you encrypt data to another person, gpg figures out which
  key to use for them.  To make sure gpg can decide well, be sure to
  keep your keyring up-to-date and only mark keys with "ownertrust" if
  you seriously believe the keyholder will only issue valid
  certifications.

People who want further detail gets into "how does gpg make that
decision?" (with the exact algorithm description)  and "what if i want
to map names or e-mail addresses to keys differently?" (answer: use
another tool that can do the bindings for you; that tool should specify
full key fingerprints to gpg for encryption)

I'm glad to see that werner thinks this might be possible for 2.1:

  https://bugs.g10code.com/gnupg/issue1143

can you or Werner point to more documentation about how the keybox will
work with OpenPGP certificates as well as X.509?  Or should i just read
the source?  I'm interested to learn more about how you break that down.

	--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/20090925/85b5c605/attachment.pgp>