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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
