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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
