Re: Decryption Fails on UserName but not on EmailAddress ???
Interesting. The key is not listed twice, but... --list-keys PrimaryUserName shows ALL THREE keys while --list-keys PrimaryEmailAddress shows only the primary host key. Could it be that the name I used for the primary key was CompanyName and the email addresses for all the people had that as their domain (ex: b...@companyname.com) ??? nschroth wrote: I have been reading previous posts on this topic but have not found my answer. When I ENcrypt on BoxA using -r UserName, decryption on BoxB errors with : decryption failed: secret key not available. However, doing the same test using the email address associated with the recipient, Decryption WORKS. Can anyone offer some reasons for this? Did we gen or export or import the key incorrectly? -- View this message in context: http://www.nabble.com/Decryption-Fails-on-UserName-but-not-on-EmailAddress-tp25577787p25661872.html Sent from the GnuPG - User mailing list archive at Nabble.com. ___ 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: Export key to multiple servers
On Mon, 2009-09-28 at 09:46 -0700, kearney wrote: I am trying to export a secret key created on my local box to multiple servers. Let's say the key is 12345678. The goal is to have 1 script which runs on all the servers to encrypt and backup the data to S3. And 1 script to decrypt the data for restores. currently i've done gpg --output secret --export-secret-keys Real name gpg --output public --export Real name secret public have been scp'd to the servers. From the servers I ran gpg --import secret gpg --import public Now, when I try to encrypt the data gpg --recipient 12345678 --encrypt file I get gpg: 12345678: There is no assurance this key belongs to the named user 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. I don't have a public key so I can't use gpg --sign-key. And if I do create a public key; can the same script be used to decrypt the files for restores across all the servers? How can I import the keys on the servers so the servers can encrypt data? And data can be decrypted using the key (12345678)? You don't need a public key to suppress this warning. The reason gpg is warning about the validity of this key is that when gpg exports keys, the ownertrust information, which is kept in ~/.gnupg/trustdb.gpg, isn't exported with the key. When you imported the keys onto your server, gpg didn't import any ownertrust information. If you created a signing key (we'll call it AABBCCDD) and signed your key 12345678 with AABBCCDD, gpg wouldn't trust the signature unless it trusted the owner of the key (ownertrust). The answer lies in fixing the ownertrust. You need to edit the key with the following commands. gpg --edit-key 12345678 trust Gpg will ask how much trust to give. Choose 5, which is ultimate, because you own the secret key. ___ 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
