Re: choosing an encryption target from a User ID
On Thursday 01 October 2009, Daniel Kahn Gillmor wrote: On 09/30/2009 05:32 PM, Ingo Klöcker wrote: 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. The current gpg behavior is to use the first key with a matching User ID, regardless of the validity of that User ID. So this causes (at best) warnings and alerts about using an invalid key or (at worst) lets someone with marginal ownertrust abuse the user by taking precedence over a fully-trusted certification if the keyring happens to be ordered in a certain way. Indeed. That's a weird policy. 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
Re: choosing an encryption target from a User ID
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
Re: choosing an encryption target from a User ID
On 09/30/2009 05:32 PM, Ingo Klöcker wrote: 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. The current gpg behavior is to use the first key with a matching User ID, regardless of the validity of that User ID. So this causes (at best) warnings and alerts about using an invalid key or (at worst) lets someone with marginal ownertrust abuse the user by taking precedence over a fully-trusted certification if the keyring happens to be ordered in a certain way. --dkg PS i hear you about being paranoid and preferring to only trust my own certifications. but the larger pool there is of people who understand the two simple concepts, the more comfortable i am granting trusted individuals marginal ownertrust, and taking advantage of the WoT to verify identities i've yet to directly verify myself. It's way better than trusting $DEITY-knows-who that comes pre-configured by default in web browsers these days ;) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Monday 28 September 2009, Daniel Kahn Gillmor wrote: On 09/25/2009 02:40 PM, Ingo Klöcker wrote: 0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo Klöcker went to the same school and the same university as I did.) 0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822, 0x91190EF9 (this last one is definitely still in use) ok, thanks, those are not expired, though i only see non-unicode in three of them: 104B0FAF and F661F608, and 91190EF9. Those keyholders should probably create a new User ID that *is* UTF-8, with the same e-mail address as the non-UTF-8 one, and encourage the people who have certified the old User ID to re-certify the new one. Once enough certifications are through on the new, valid one, they can revoke the old one and move forward with a fully OpenPGP-compliant key. Yes, I suppose this would be a sensible solution. I don't see why harmless changes (see David's example) shouldn't be ignored. If the user hard-coded the key Alice1, then what's wrong with using this key as long as it's valid. Obviously, any changes making a hard-coded key invalid need to be escalated and such a key must not be used anymore by the MUA. If the user hard-coded a specific key (by fingerprint) to the Alice User ID, then of course GPG should respect that preference (and it should emit warnings if the key ever becomes invalid), but i don't think that users should be asked to make permanent choices like this, since they might become invalidated by future circumstances; how will they know that another (maybe better) choice is available, or should be made? If Alice does not tell them, then they might not know this. But I'm not sure whether this is a common problem or more an academic problem. Let's say Alice loses her first key and cannot revoke it because she didn't create a revocation certificate. 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. So I don't really see the problem with a hardcoded choice. If for some email address multiple matching valid keys are found by KMail (or rather gpgme) then KMail asks the user which key(s) to use (and then remembers the user's choice). This transparency gives me a better feeling than some automagic behind-my-back key selection based on user ID/email address. I hear what you're saying, but i think there are two problems with it: 0) for many users, they are being asked to make a choice that they don't understand; there are few things more frustrating than this. If the tool *can* make a good choice based on the knowledge available to it, it shouldn't need to pester the user, who may or may not have as much understanding of the problem space. 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. 1) users are being asked to make an effectively permanent decision, even though relevant circumstances may change in the future. Presumably, this binding will produce warnings (with the option to change the binding) if the bound key suddenly actually drops into unknown calculated validity (for example, if you decide to revoke ownertrust on a relevant intermediary; has this been tested?) But there might be other changes that make this selection suboptimal without causing it to throw warnings. 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? In the past, when I worked at the university, I used a private/home key and a work key. At home I could read anything. At work I could only read messages encrypted with my work key. So anything I was supposed to read at work needed to be encrypted with my work key. To make things more complicated my home key did have my work address as one user ID. So hardcoding my work address to my work key was basically mandatory. 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
Re: choosing an encryption target from a User ID
Thanks for the discussion, Ingo! This is really useful to me, and i appreciate the thought you've obviously put in here. 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? 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? b) who can i rely on to identify others? 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. 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. * Some people also have old keys that they have accidentally lost access to. once that happens, it's too late. 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. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/25/2009 02:40 PM, Ingo Klöcker wrote: 0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo Klöcker went to the same school and the same university as I did.) 0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822, 0x91190EF9 (this last one is definitely still in use) ok, thanks, those are not expired, though i only see non-unicode in three of them: 104B0FAF and F661F608, and 91190EF9. Those keyholders should probably create a new User ID that *is* UTF-8, with the same e-mail address as the non-UTF-8 one, and encourage the people who have certified the old User ID to re-certify the new one. Once enough certifications are through on the new, valid one, they can revoke the old one and move forward with a fully OpenPGP-compliant key. True. Actually, I lied about KMail using key IDs. Since about 6.5 years KMail uses gpgme and leaves all of those hairy details (like telling gpg what keys to use) to this library. This seems like a reasonable stance for authors of MUAs and Plugins to use. Werner, it looks like you're the upstream author on GpgME; does GpgME do any different selection technique than GPG? I don't see why harmless changes (see David's example) shouldn't be ignored. If the user hard-coded the key Alice1, then what's wrong with using this key as long as it's valid. Obviously, any changes making a hard-coded key invalid need to be escalated and such a key must not be used anymore by the MUA. If the user hard-coded a specific key (by fingerprint) to the Alice User ID, then of course GPG should respect that preference (and it should emit warnings if the key ever becomes invalid), but i don't think that users should be asked to make permanent choices like this, since they might become invalidated by future circumstances; how will they know that another (maybe better) choice is available, or should be made? If for some email address multiple matching valid keys are found by KMail (or rather gpgme) then KMail asks the user which key(s) to use (and then remembers the user's choice). This transparency gives me a better feeling than some automagic behind-my-back key selection based on user ID/email address. I hear what you're saying, but i think there are two problems with it: 0) for many users, they are being asked to make a choice that they don't understand; there are few things more frustrating than this. If the tool *can* make a good choice based on the knowledge available to it, it shouldn't need to pester the user, who may or may not have as much understanding of the problem space. 1) users are being asked to make an effectively permanent decision, even though relevant circumstances may change in the future. Presumably, this binding will produce warnings (with the option to change the binding) if the bound key suddenly actually drops into unknown calculated validity (for example, if you decide to revoke ownertrust on a relevant intermediary; has this been tested?) But there might be other changes that make this selection suboptimal without causing it to throw warnings. so i'm not a big fan of prompting users to hardcode bindings in general (though i certainly support allowing users to hardcode bindings if they prefer) --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/24/2009 04:56 PM, Ingo Klöcker wrote: Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created with PGP 6 (or earlier) where the user ID is not UTF-8 encoded? hm; 0xCB0D4CAF looks to me like it expired 5 years ago; and 0xAB1BC4E6 doesn't appear to be available on the public keyservers at all. Do you have any examples that are both public and still valid? RFC 2440 (over a decade ago) mandates UTF-8 for user IDs: http://tools.ietf.org/html/rfc2440#section-5.11 Moreover, user IDs are not unique while key IDs (usually) are. So if you want to be sure that the correct key is used you cannot use the user ID. 8-xdigit key IDs are fairly easy to replicate with today's hardware, so relying on their uniqueness is not a good idea from a security perspective. Full 40-xdigit fingerprints are probably effectively unique for the time being, though. You're not the first person to suggest that supplying the key ID (or fingerprint) directly is the best approach, but doing this just moves a serious problem from GnuPG onto the shoulders of the user (or their MUA or other tools). The problem that gets shifted in this case is: what key should you use to encrypt data to a specific person? This is a potentially complicated problem, and the right answer changes in the face of changed/updated/revoked certifications, expirations, altered trust relationships, etc. Asking the user (or their MUA) to hard-code a single key ID means that you're asking them to ignore all these possible changes when they happen. Asking every MUA to implement their own mapping from User IDs to key IDs seems like a recipe for either weird divergence (should kmail select a different key than enigmail for f...@example.org?) or plain insecure mappings (e.g. an MUA developer who doesn't understand the problem of certificate validation as well as the GnuPG developers). Since most of these tools rely on gpg as a backend, implementing a more-reasonable choice in gpg seems like a good idea. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Sep 25, 2009, at 10:04 AM, Daniel Kahn Gillmor wrote: Since most of these tools rely on gpg as a backend, implementing a more-reasonable choice in gpg seems like a good idea. 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. 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. We have a marginal trust in both Alices through Baker, so following the suggested algorithm we pick Alice2 (as it is a newer key). Now, the user imports Charlie's key. This completely changes the calculation: we have full trust in Alice1 through Charlie, so Alice1 is now fully trusted. We switch over to encrypting to Alice1 - it's the older key, but it has full trust. Then, the user imports Dan's key. This completely changes the calculation again: we now have full trust in both Alices, so we again pick the more recent key, and pick Alice2. Then there is the case where someone doesn't automatically rebuild their trustdb - they can be in a position of having GPG pick one key, then a rebuild is triggered, causing the other key to be picked. I'm not against that behavior - it's reasonable and makes sense... to someone who really understands the web of trust and OpenPGP. 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). David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Friday 25 September 2009, Daniel Kahn Gillmor wrote: On 09/24/2009 04:56 PM, Ingo Klöcker wrote: Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created with PGP 6 (or earlier) where the user ID is not UTF-8 encoded? hm; 0xCB0D4CAF looks to me like it expired 5 years ago; and 0xAB1BC4E6 doesn't appear to be available on the public keyservers at all. I guess that's just my luck picking exactly those two keys in my keyring that have either expired or are not publically available. :-) Do you have any examples that are both public and still valid? 0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo Klöcker went to the same school and the same university as I did.) 0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822, 0x91190EF9 (this last one is definitely still in use) RFC 2440 (over a decade ago) mandates UTF-8 for user IDs: http://tools.ietf.org/html/rfc2440#section-5.11 I'm fully aware of this. Moreover, user IDs are not unique while key IDs (usually) are. So if you want to be sure that the correct key is used you cannot use the user ID. 8-xdigit key IDs are fairly easy to replicate with today's hardware, so relying on their uniqueness is not a good idea from a security perspective. Full 40-xdigit fingerprints are probably effectively unique for the time being, though. True. Actually, I lied about KMail using key IDs. Since about 6.5 years KMail uses gpgme and leaves all of those hairy details (like telling gpg what keys to use) to this library. You're not the first person to suggest that supplying the key ID (or fingerprint) directly is the best approach, but doing this just moves a serious problem from GnuPG onto the shoulders of the user (or their MUA or other tools). The problem that gets shifted in this case is: what key should you use to encrypt data to a specific person? This is a potentially complicated problem, and the right answer changes in the face of changed/updated/revoked certifications, expirations, altered trust relationships, etc. Asking the user (or their MUA) to hard-code a single key ID means that you're asking them to ignore all these possible changes when they happen. I don't see why harmless changes (see David's example) shouldn't be ignored. If the user hard-coded the key Alice1, then what's wrong with using this key as long as it's valid. Obviously, any changes making a hard-coded key invalid need to be escalated and such a key must not be used anymore by the MUA. Asking every MUA to implement their own mapping from User IDs to key IDs seems like a recipe for either weird divergence (should kmail select a different key than enigmail for f...@example.org?) If for some email address multiple matching valid keys are found by KMail (or rather gpgme) then KMail asks the user which key(s) to use (and then remembers the user's choice). This transparency gives me a better feeling than some automagic behind-my-back key selection based on user ID/email address. or plain insecure mappings (e.g. an MUA developer who doesn't understand the problem of certificate validation as well as the GnuPG developers). Full ACK. That's why MUA developers should use gpgme or an appropriate binding. Since most of these tools rely on gpg as a backend, implementing a more-reasonable choice in gpg seems like a good idea. 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
Re: choosing an encryption target from a User ID
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
Re: choosing an encryption target from a User ID
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
Re: choosing an encryption target from a User ID
On Wed, 23 Sep 2009 19:04, d...@fifthhorseman.net said: Has this been made this clear to collaborating MUA/plugin developers? I think the auto select a key step for MUAs or plugins is often implemented as let gpg pick the key based on the user ID. I added PGP/MIME crypto to several MUA and as far as I can remember I always used the approach to listy all keys and then select the bext matching one. Mutt used this even before gpg; in recent code bases grep for crypt_getkeybyaddr. I have not looked at the enigmail code but I recall that the first PGP/MIME implementation for Mozilla (~2000) worked as I described. Unfortunately they refused this code. https://bugs.g10code.com/gnupg/issue1143 Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Thursday 24 September 2009, Daniel Kahn Gillmor wrote: On 09/23/2009 06:04 PM, Ingo Klöcker wrote: I'm pretty sure that this will break horribly as soon as the user ID contains non-ASCII characters (as does my user ID). For exactly this reason I made KMail use the key ID instead of the user ID about 7 years ago. What makes you think that non-ASCII characters would break a match? Presumably, all the tools are passing UTF-8 strings to each other, and GPG can easily find a match based on such a string. Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created with PGP 6 (or earlier) where the user ID is not UTF-8 encoded? KMail applies some heuristics to guess the correct encoding if UTF-8 doesn't seem to work, but even if KMail guesses wrong and is not able to decode the user ID properly it's still possible to use such a key for encryption. Moreover, user IDs are not unique while key IDs (usually) are. So if you want to be sure that the correct key is used you cannot use the user ID. For example, it certainly works fine from the shell: 0 d...@pip:~$ echo test | \ gpg --encrypt --trust-model always -r 'Ingo Klöcker' | \ gpg --list-packets :pubkey enc packet: version 3, algo 16, keyid 30CFDDC732319538 data: [2047 bits] data: [2048 bits] :encrypted data packet: length: 64 mdc_method: 2 gpg: encrypted with 2048-bit ELG-E key, ID 32319538, created 2000-10-16 Ingo Klöcker kloec...@kde.org gpg: decryption failed: secret key not available 2 d...@pip:~$ Good to see that it works nowadays for UTF-8 encoded user IDs on systems using a UTF-8 locale. Is enigmail really still using the user ID? I haven't dug into it deeply, but what i observed from my tests was that if i switched the order of keys in my gpg keyring, enigmail selected a different key for a recipient who had two keys with matching User IDs. So i suspect that Enigmail is indeed passing the e-mail address at least (if not the name) to gpg to select a reasonable key for encryption. Yeah, not very clever if you ask me. But, of course, I'm biased. :-) 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
Re: choosing an encryption target from a User ID
On 09/22/2009 07:16 PM, David Shaw wrote: It doesn't work that way. The default is the first valid key. It's been that way in the PGP world since before GPG as a product was written. If you want to propose a specific alternative, I'm ready to listen, but I'm not going to defend the default behavior of 15+ years. OK; if i'm proposing one specific alternative, it would be: Select the most recently-generated valid key that has a non-revoked, non-expired encryption-capable subkey, and has a matching user ID with the highest-available-class of calculated validity for the given User ID. That is, if you have the following keys with matching User IDs and non-expired, non-revoked encryption-capable subkeys (or encryption-capable primary-keys): * A: unknown calculated validity, primary key created 2005-02-01 * B: marginal calculated validity, primary key created 2004-01-02 * C: full calculated validity, primary key created 2003-08-01 * D: full calculated validity, primary key created 2003-05-02 * E: marginal calculated validity, primary key created 2004-10-30 then C would be the most reasonable default choice for encryption, due to its full validity and creation date. If C and D weren't in the keyring, then E would be the next-best choice. A simple algorithm for doing this is to walk through the keys in the keyring with a matching User ID; keeping track of the current best key. When you look at a new key, compare validity with the current best. If the new key has better validity, use it instead of the current best. If the new key has worse validity, pass it over and move on. If the new key has the same validity as the current best, compare primary key creation dates: if the new key was created more recently, use it instead of the current best. It's used everywhere user IDs are referenced in the product. --list-keys. --edit-key, --sign-key, etc, etc. list-keys merely produces a list of *all* matching keys, and the documentation makes no promises about ordering; i don't much care what order they come out in this case. For edit-key and sign-key, the proposed heuristic makes less sense; there are already significant usability concerns with using either of these subcommands when specifying a key by an ambiguous User ID, and i'm not sure that this specific change would have any effect (good or bad) on the usability of these commands. At any rate, the usability concerns there seem less worrisome than the security concern associated with sending data encrypted to the wrong key. I hear you that the historic default is first valid key, but there is little documentation about keyring ordering in the man page, nor is there any documentation that the in-keyring ordering can have significant security consequences. And i could find no documentation about how to change the order of keys in any keyring. Since the ordering is currently relevant in several places, i'd assume there would be a way to change it explicitly, but i can't seem to find it, other than the export/delete/import push-to-end procedure i noted earlier. Is there any other interface to change the keyring ordering that i've missed? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Wed, 23 Sep 2009 15:34, d...@fifthhorseman.net said: OK; if i'm proposing one specific alternative, it would be: Please keep in mind that using a user ID is just to help the user in the most common case. Any proper mail tool won't accept such a solution but either presenr the user a list of matching keys and let him select a key or auto select the key based on such information. If possible you should use the fingerprint to select a key. Thus I consider this a wish for a future version. Feel free to add such a request to the bug tracker. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/23/2009 12:17 PM, Werner Koch wrote: Please keep in mind that using a user ID is just to help the user in the most common case. Any proper mail tool won't accept such a solution but either presenr the user a list of matching keys and let him select a key or auto select the key based on such information. Has this been made this clear to collaborating MUA/plugin developers? I think the auto select a key step for MUAs or plugins is often implemented as let gpg pick the key based on the user ID. I observed this exact behavior from enigmail, and it changed when i re-ordered my keys in my gpg keyring. You can see the discussion here: http://www.mozdev.org/pipermail/enigmail/2009-September/011491.html So it sounds like enigmail is relying on gpg at some level to do key selection among multiple User ID matches. It seemed to me that I could ask enigmail to improve their key selection process (fixing things just for enigmail users), or i could ask gpg to change the selection process (fixing things for enigmail users and all other gpg users). Thus I consider this a wish for a future version. Feel free to add such a request to the bug tracker. thanks, done: https://bugs.g10code.com/gnupg/issue1143 Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Wednesday 23 September 2009, Daniel Kahn Gillmor wrote: On 09/23/2009 12:17 PM, Werner Koch wrote: Please keep in mind that using a user ID is just to help the user in the most common case. Any proper mail tool won't accept such a solution but either presenr the user a list of matching keys and let him select a key or auto select the key based on such information. Has this been made this clear to collaborating MUA/plugin developers? I think the auto select a key step for MUAs or plugins is often implemented as let gpg pick the key based on the user ID. I'm pretty sure that this will break horribly as soon as the user ID contains non-ASCII characters (as does my user ID). For exactly this reason I made KMail use the key ID instead of the user ID about 7 years ago. Is enigmail really still using the user ID? 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
Re: choosing an encryption target from a User ID
On 09/23/2009 06:04 PM, Ingo Klöcker wrote: I'm pretty sure that this will break horribly as soon as the user ID contains non-ASCII characters (as does my user ID). For exactly this reason I made KMail use the key ID instead of the user ID about 7 years ago. What makes you think that non-ASCII characters would break a match? Presumably, all the tools are passing UTF-8 strings to each other, and GPG can easily find a match based on such a string. For example, it certainly works fine from the shell: 0 d...@pip:~$ echo test | \ gpg --encrypt --trust-model always -r 'Ingo Klöcker' | \ gpg --list-packets :pubkey enc packet: version 3, algo 16, keyid 30CFDDC732319538 data: [2047 bits] data: [2048 bits] :encrypted data packet: length: 64 mdc_method: 2 gpg: encrypted with 2048-bit ELG-E key, ID 32319538, created 2000-10-16 Ingo Klöcker kloec...@kde.org gpg: decryption failed: secret key not available 2 d...@pip:~$ Is enigmail really still using the user ID? I haven't dug into it deeply, but what i observed from my tests was that if i switched the order of keys in my gpg keyring, enigmail selected a different key for a recipient who had two keys with matching User IDs. So i suspect that Enigmail is indeed passing the e-mail address at least (if not the name) to gpg to select a reasonable key for encryption. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
Daniel Kahn Gillmor wrote: when encrypting messages to a user ID with multiple matching keys with full calculated validity, gpg seems to just choose the first matching key, for some definition of first -- i think it's decided by chronological age of first import into the local keyring. IIRC, it's the first usable key with a matching User ID. Period. First one it can use. PS: Would you touch the membership file on zimmermann.mayfirst.org? ISP DHCPed a new IP when I replaced a dead router over the weekend. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=help Q:Just how do the residents of Haiku, Hawai'i hold conversations? A:An odd melody / island voices on the winds / surplus of vowels signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 John Clizbe wrote: IIRC, it's the first usable key with a matching User ID. Period. First one it can use. My usual 'solution' for this is to 'Disable' the non-preferred or unused Key until such time as it is Revoked or I have been otherwise informed it is deprecated beyond any further use. JOHN ;) Timestamp: Tuesday 22 Sep 2009, 16:09 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJKuS8VAAoJEBCGy9eAtCsPIAMH/iHFYbkgRit0CWEPDq9Oyhdi PvJwBnppkbU1YXF54MEV2y9+88FSl3A5crZyBkLt+MKvMEuYZO906+7xxmNQZ6u6 7wCNYjX5VbiKVHyT4k4N6AJBn4fuZB3jswK9yWylo2Loz2YjDfvnnpXIbxhuM2co ct8aiCjOKPMdvaw9KwhgcczOia0GGZlK9Rp7qCrt6TS/WguRecQX9h/NpZR8jjSY S6MpSIuVXvoPWU/GlednH2Rmp11f7xdOKHwYkwDV9gq03ql8l8sTdzFr6T0LEBY+ tEZRroTaoUfu53+yvJm75kkkqBlRpbVEphKQaGbaSWaxCDaoU5kYkfLlztlxXlQ= =X28H -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Sep 22, 2009, at 1:11 PM, Daniel Kahn Gillmor wrote: when encrypting messages to a user ID with multiple matching keys with full calculated validity, gpg seems to just choose the first matching key, for some definition of first -- i think it's decided by chronological age of first import into the local keyring. This does not seem to be the best heuristic. here are some other proposed heuristics for choosing among multiple keys with full calculated User ID validity during encryption: 0) choose the most recently-created key 1) choose the key with the strongest supported encryption-capable subkey (by bitlength?) 2) encrypt to *all* matching keys The problem with this sort of thing is that for every possible heuristic we can come up with, there is going to be someone who that heuristic breaks. GnuPG has done the first matching key since the beginning, as did (old) PGP[1]. That behavior is baked deeply into systems. David [1] PGP has a GUI nowadays, so this sort of thing doesn't apply in the same way any longer. I don't have my copy of PGP command line online at the moment, so I can't check what it does, but I'd be surprised if it didn't either take the first one or give an error message. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 David Shaw wrote: [1] PGP has a GUI nowadays, so this sort of thing doesn't apply in the same way any longer. I don't have my copy of PGP command line online at the moment, so I can't check what it does, but I'd be surprised if it didn't either take the first one or give an error message. Like GPG it utilizes the 1st encountered Key that matches the Send To: address is valid. JOHN ;) Timestamp: Tuesday 22 Sep 2009, 16:57 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJKuTosAAoJEBCGy9eAtCsPZH8H/1ARVU6lWN9IoaWrMGgf/z86 U33uTXD5rRMUZcdpmoFvwkso6Gc5vU7AM6yYcl5A8yYBWkQ9USfVhGZEVB7pX8/n AGKcHfm2TALDxCknqQWXrI7k1CHY10nQ9gNjwHooHTYIV1gTavm6tQGYPmQOsOds aKBITuxIw3hIcb6tm8gObi4V0I1NT7Qp4oeMWHJAhcDHJJ/KIoSRe4a4N1176eYC vdc2S6VT7tLqiuAH22np4e7Je1epTTq+0QNwnrKuMLTv80EGnYf7qixotOhaNWrC 18TSYarG9t5biEzc/vJEAWQEdCoN6af+mr/2aiGNBX5ikh/mRC/bA180ejtoKR0= =dbA2 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel Kahn Gillmor wrote: On 09/22/2009 04:57 PM, John W. Moore III wrote: Like GPG it utilizes the 1st encountered Key that matches the Send To: address is valid. this is not what gpg does. gpg simply chooses the first key with a matching user ID, whether or irrespective of the calculated validity of the User ID in question. I was referring to the validity of the Key; _not_ the UID. If the Key isn't expired/revoked or disabled; GPG will use it when it comes upon it in the 1st order encountered. So does Command Line PGP. JOHN ;) Timestamp: Tuesday 22 Sep 2009, 17:07 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJKuTygAAoJEBCGy9eAtCsPB+UH/0OUuuUAXhTG7n4lTpXkedjO TwsYHPLsCvTws9Zgym+Ojw/NuPeD27hb82AWHz128mF+iL/88TJ5MCdLb/RV7tm8 fAMlSDVDjJQELUDKwLyhT3+eFKSh3SU+PegRmf0yZzEdj01Fv9LURb9O7e8TxXWQ sOMTxv9b4LL68ievBfWURE+AW2MtVBGRCfrIbbEQfeMsMGjKDD0jTZ+CoOWuaeY3 rWhSHQt8Fn23r3Wxc0D3FL1Tkk3KojKNt39NQI9XBMk/1D3/CIz4YS1Dw3dOVH0z 8FI0eRLTnm7RIN6i5C5cDOLUuUBdAkTmOSJ9zkikBAeOfs7K5i/rQKDDZjjAMe0= =W8qb -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/22/2009 04:09 PM, John W. Moore III wrote: John Clizbe wrote: IIRC, it's the first usable key with a matching User ID. Period. First one it can use. thanks for catching that, John. It appears that if the first key with a matching User ID doesn't have full calculated validity, the user gets a scary warning that There is no assurance this key belongs to the named user, and then: It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. It does this even if there is a full-valid match later in the keyring! This doesn't seem like friendly or reasonable behavior for the power user, let alone the novice user. My usual 'solution' for this is to 'Disable' the non-preferred or unused Key until such time as it is Revoked or I have been otherwise informed it is deprecated beyond any further use. i'm assuming you mean gpg --edit-key 0xDECAFBAD followed by the disable subcommand. What do y'all think should actually be happening here? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Sep 22, 2009, at 4:40 PM, Daniel Kahn Gillmor wrote: On 09/22/2009 04:09 PM, John W. Moore III wrote: John Clizbe wrote: IIRC, it's the first usable key with a matching User ID. Period. First one it can use. thanks for catching that, John. It appears that if the first key with a matching User ID doesn't have full calculated validity, the user gets a scary warning that There is no assurance this key belongs to the named user, and then: It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. It does this even if there is a full-valid match later in the keyring! This doesn't seem like friendly or reasonable behavior for the power user, let alone the novice user. My usual 'solution' for this is to 'Disable' the non-preferred or unused Key until such time as it is Revoked or I have been otherwise informed it is deprecated beyond any further use. i'm assuming you mean gpg --edit-key 0xDECAFBAD followed by the disable subcommand. What do y'all think should actually be happening here? I think the current behavior is the right one. Otherwise we break however many baked-in uses out there (scripts, etc), to say nothing of having to explain to people why a particular key was chosen. We pick the first valid key cannot be misunderstood or confuse anyone. Yes, it's wrong for some situations. But every behavior is wrong for some situations. This particular wrong behavior has almost 20 years of history behind it. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/22/2009 06:30 PM, David Shaw wrote: I think the current behavior is the right one. Otherwise we break however many baked-in uses out there (scripts, etc), to say nothing of having to explain to people why a particular key was chosen. We pick the first valid key cannot be misunderstood or confuse anyone. well, i'm living proof that it can confuse people, and that people can misunderstand it. It took me a while to sort out: a) what it was doing specifically (i originally thought it was sorting by key creation date) b) how to change the ordering of keys in a keyring (so far, i've only figured out how to move a given key to the end of the list: gpg --export --export-options export-local $KEYID tmpfile gpg --delete-key $KEYID gpg --import --import-options import-local tmpfile I suppose i could do arbitrary bubble-sort-ish reorderings with this primitive, too; is there another way?) c) that gpg is even willing to settle on a key with a matching User ID with no calculated validity (e.g. if i added a user ID of Daniel Kahn Gillmor ds...@jabberwocky.com to my key, even if no one else certified it, then anyone who had met me before meeting you would need to specify your key by key ID, instead of by e-mail address!) Yes, it's wrong for some situations. But every behavior is wrong for some situations. This particular wrong behavior has almost 20 years of history behind it. I hear you. I've offered some concrete examples of ways that the current behavior breaks things. Can you give me an example of a script that has this behavior baked in to the point where adopting a better heuristic would break it? Also, i believe this behavior is *only* relevant in situations where the user asks gpg to encrypt something to a name or User ID. Is that right? or are there other circumstances in gpg where the choose the first matching User ID heuristic is used? Thanks for thinking through this with me, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Sep 22, 2009, at 6:54 PM, Daniel Kahn Gillmor wrote: Can you give me an example of a script that has this behavior baked in to the point where adopting a better heuristic would break it? It doesn't work that way. The default is the first valid key. It's been that way in the PGP world since before GPG as a product was written. If you want to propose a specific alternative, I'm ready to listen, but I'm not going to defend the default behavior of 15+ years. Also, i believe this behavior is *only* relevant in situations where the user asks gpg to encrypt something to a name or User ID. Is that right? or are there other circumstances in gpg where the choose the first matching User ID heuristic is used? It's used everywhere user IDs are referenced in the product. --list- keys. --edit-key, --sign-key, etc, etc. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
