Re: bug-like: strange behaviour of addrevoker
On Tue, 5 Nov 2013 23:13, mailinglis...@hauke-laging.de said: revokers. But that didn't work as expected. After entering the command addrevoker I was asked to enter the user ID of the respective key. Why the user ID and not the key ID or fingerprint? Does that make any sense? You may use any way to specify a user id. It is the same code as used when you fire up gpg --key-edit USERID with the only restriction that the key must have certify capability which is always the case for a primary key. nor 0x1a571df5 works. Even worse: The email address doesn't work either (both ha...@laging.de and ha...@laging.de). If you have the two user IDs, gpg can't decide which to use. Thus you need to use the keyid or the fingerprint. Please check again and if you can't make it work, please create a test case for us. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
question about public keys
Hi A couple of years ago I created a gpg key for an account that is use to transfer documents with vendors. It's worked fine. We now have a new vendor that won't accept the public key because of the expiration date. I don't see a way to create another public key for this account with the shorter expiration date. Replacing the current public key will disrupt business with existing customers. Is there a solution other than creating another account with its own gpg key? Thanks Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone: 509.375.2687 Fax: 509.375.2330 Email: cathy.sm...@pnnl.gov ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
On 06/11/13 23:28, Leo Gaspard wrote: The fact that others could get just the same effect by twisting their WoT parameters is not an issue to me. Firstly, because there are few trust signatures (according to best practices I read, that said trust signatures are mainly made for closed-system environments), so WoT rarely expands outwards of one signature by someone you know. Let's leave trust signatures out of the equation, it makes it a lot more complicated and they are rarely used. I also don't see the relation between the statements in this quote here. But mostly because signing is an attestion of your belief someone is who (s)he is. Thus, if you believe someone is who the UID states (s)he is as much as if you met him/her in person and followed the whole verification process, I would not mind your exporting signatures of the key. I get the feeling you're partly responding to my adamant statements earlier, but you're confusing the situation I was responding to. I think you're saying: Person X tells me their key is K1. I blindly trust person X, and I know for a fact that person X was the one who told me K1 is his key. That is, you were in the same room, or you recognised their voice on the telephone, or something similar. This is acceptable to many people as a verification. But this is not the situation I was talking about. It's this: Person X (having key K1) has signed key K2, asserting that it is held by Y. Since you blindly trust X, you can assign him full (or hell, ultimate if you prefer) ownertrust, and key K2 is valid for you. You don't need to sign K2 anymore, because it is already valid since you expressed your trust to GnuPG, and GnuPG uses it to validate that it belongs to Y. Now, what Stan Tobias appeared to want, is sign key K2 himself, probably to express to others in the Web of Trust that he believes K2 to be valid. But this doesn't add any additional verification of key validity to the Web of Trust, it's noise. Because anyone else can look at the signature made by X, and decide: I trust X fully as well. They assign full trust to X, and K2 becomes valid. Let's get back to ownertrust: in the Web of Trust, ownertrust is an expression of how well you think other people verify identities before they sign a key. If you sign key K2 based on X's signature, you haven't verified Y's identity. You've probably verified X's identity, but not Y's. So you shouldn't sign K2. You might believe Y when he or she walks up to you and says: my name is Y and K2 is my key. But that is not what happened; X said: K2 is Y's key. Y didn't say anything to you, let alone that you verified it was actually Y talking. That's the absolutely necessary part of verification: you believe that it was actually Y that told you K2 is theirs. Just believing K2 is Y's key is not verification; it's key validity. I'll give an example. In the Web of Trust, key validity is a thing that can gradually build up until it passes a certain point where we say: I have so much proof that it appears to be valid, that I conclude it's, within reason, valid. This is why you have completes needed, marginals needed, and max cert depth. The latter says: once we pass a certain depth, my proof of identity becomes so indirect I don't wish to trust that information anymore. I will paint a picture with the default settings, completes 1, marginals 3, max depth 5. Suppose A has signed B. There are three people C, D and E, who have full trust in A. They do what I'm arguing against: they sign key B as well, based on their trust of A. Now I come along. I actually have key A valid as well, but quite indirectly: it is at level 4. I know A, but ownertrust is very personal. I think A does an okay job of verifying identities, but not to the rigorous level I personally demand. I work with pretty sensitive stuff, and my standards are high (I'm painting a picture here, not describing reality). So I assign him marginal ownertrust. Now what I would expect, is that I need some more signatures, and B will become valid at level 5, the level where I have configured GnuPG to say: okay, this is deep enough, I will not take into account B's signatures on other keys because the proof becomes too indirect. However, I also know C, D and E, signed their keys and assigned them marginal ownertrust because I was under the impression they also verify identities pretty well. I don't know that they go around signing keys based on other people's signatures. C, D and E are thus at level 1 in my web. They all signed B's key, so I think: that's reasonable proof that B is valid. Not only do I think that, so does GnuPG. It leads to B's key being valid at level 2. B can have another few levels of indirection before I consider the path too long. In fact, for signature paths through B, it effectively just changed my max cert depth. B belongs at level 5, because the proof of validity is very indirect in my *own* web, but he's at level 2, so my max cert depth has
Re: question about public keys
On 11/06/13 23:57, Smith, Cathy wrote: Hi A couple of years ago I created a gpg key for an account that is use to transfer documents with vendors. It's worked fine. We now have a new vendor that won't accept the public key because of the expiration date. I don't see a way to create another public key for this account with the shorter expiration date. Replacing the current public key will disrupt business with existing customers. Is there a solution other than creating another account with its own gpg key? You have a number of options: 1. Edit the expiration date of the existing key, and then re-circulate it. Vendors with the old key will be able to carry on working, the new one can use the key with the shorter expiration date. As it comes close to expiration, you can re-edit the expiration date to extend it. However, this might not suit your new client's requirements. 2. Generate a new keypair with the same email address as the old one, and only send it to the new client. However, if it gets circulated to other clients, it might cause confusion over which key to use. You can generate a new keypair with gpg --gen-key. 3. Depending on what your new client's objections are, it might be sufficient to generate a new encryption subkey within your existing master key. The new subkey can have a different expiration date to the master key. Most of your existing clients will continue using the existing encryption subkey with a long expiration date; the new client can specifically choose to use the new subkey with a shorter expiration date. When the new subkey expires, you can simply create another one with a new expiration date. You can add a subkey by running gpg --edit-key key_id and then running the command addkey. HTH... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
On Thu, Nov 07, 2013 at 11:48:07AM +0100, Peter Lebbing wrote: On 06/11/13 23:28, Leo Gaspard wrote: But mostly because signing is an attestion of your belief someone is who (s)he is. Thus, if you believe someone is who the UID states (s)he is as much as if you met him/her in person and followed the whole verification process, I would not mind your exporting signatures of the key. I get the feeling you're partly responding to my adamant statements earlier, but you're confusing the situation I was responding to. Well... The answer to your previous message was in my first two paragraphs. The rest of my answer, to which you answered, was mostly thinking over some debate that aroused earlier, and whose authors I do not remember. Anyway, I think you answered the most important part of my last message. I think you're saying: Person X tells me their key is K1. I blindly trust person X, and I know for a fact that person X was the one who told me K1 is his key. That is, you were in the same room, or you recognised their voice on the telephone, or something similar. This is acceptable to many people as a verification. But this is not the situation I was talking about. It's this: Person X (having key K1) has signed key K2, asserting that it is held by Y. Since you blindly trust X, you can assign him full (or hell, ultimate if you prefer) ownertrust, and key K2 is valid for you. You don't need to sign K2 anymore, because it is already valid since you expressed your trust to GnuPG, and GnuPG uses it to validate that it belongs to Y. Now, what Stan Tobias appeared to want, is sign key K2 himself, probably to express to others in the Web of Trust that he believes K2 to be valid. But this doesn't add any additional verification of key validity to the Web of Trust, it's noise. Because anyone else can look at the signature made by X, and decide: I trust X fully as well. They assign full trust to X, and K2 becomes valid. Except they do not have to know X, nor that he makes perfectly reasonable decisions in signing keys. And I believe it's not noise. Let's make an example in the real world : * I would entrust X with my life * X would entrust Y with his life, without my knowing it * Thus, if I actually entrusted X with my life, why should I be frightened if X asked Y to take care of me ? Provided, of course, X told me he was letting Y take care of me. After all, I would entrust X with my life, so I should just agree to any act he believes is good for me. (That's what I called blind trust. Somewhat more than full trust, I believe.) Let's get back to ownertrust: in the Web of Trust, ownertrust is an expression of how well you think other people verify identities before they sign a key. If you sign key K2 based on X's signature, you haven't verified Y's identity. You've probably verified X's identity, but not Y's. So you shouldn't sign K2. So, is a signature a matter of belief in the validity of the key or of actual work to verify the key ? You might believe Y when he or she walks up to you and says: my name is Y and K2 is my key. But that is not what happened; X said: K2 is Y's key. Y didn't say anything to you, let alone that you verified it was actually Y talking. That's the absolutely necessary part of verification: you believe that it was actually Y that told you K2 is theirs. Just believing K2 is Y's key is not verification; it's key validity. I'll give an example. In the Web of Trust, key validity is a thing that can gradually build up until it passes a certain point where we say: I have so much proof that it appears to be valid, that I conclude it's, within reason, valid. This is why you have completes needed, marginals needed, and max cert depth. The latter says: once we pass a certain depth, my proof of identity becomes so indirect I don't wish to trust that information anymore. I will paint a picture with the default settings, completes 1, marginals 3, max depth 5. If I understood correctly, the depth parameter you are talking about is useless, except in case there are trust signature. And you agreed with me for them to be taken out of the equation. Suppose A has signed B. There are three people C, D and E, who have full trust in A. They do what I'm arguing against: they sign key B as well, based on their trust of A. Now I come along. I actually have key A valid as well, but quite indirectly: it is at level 4. I know A, but ownertrust is very personal. I think A does an okay job of verifying identities, but not to the rigorous level I personally demand. I work with pretty sensitive stuff, and my standards are high (I'm painting a picture here, not describing reality). So I assign him marginal ownertrust. Now what I would expect, is that I need some more signatures, and B will become valid at level 5, the level where I have configured GnuPG to say: okay, this is deep enough, I will not take into
Re: trust your corporation for keyowner identification?
On 2013-11-07 17:09, Leo Gaspard wrote: If I understood correctly, the depth parameter you are talking about is useless, except in case there are trust signature. And you agreed with me for them to be taken out of the equation. Of course it's not useless. You seem to misunderstand the Web of Trust. I'll give an example. I know and trust the people A, B, C, D and E. A has signed B, B has signed C, C has signed D, D has signed E, and E has signed F. I meet up with A, verify their identity, and sign their key. I assign ownertrust to A, B, C, D and E. Et voilà, the keys A, B, C, D and E are all valid, without me needing to meet up with my other friends to verify their key details. A is at level 1, B at 2, C at 3, D at 4, and E at 5. Unfortunately, F won't get valid because it is at level 6. Now suppose C signs F as well. F is now at level 4, so it becomes valid. However, I don't trust F, so even if F now signs G, G won't become valid. Signatures indicate verification, not trust or belief. Trust is in your trust database or in trust signatures, but the latter are not commonly used. Belief is expressed in validity calculated from your trust database and signatures. I don't know if you can choose to disagree with GnuPG, that is, if you don't believe a key is valid even though GnuPG calculated that it is. I could get back to all the other points you raise, but I think it's a waste of time when you have reasoned from the standpoint that to get a key to be valid, you need to sign it, and that is how it looks to me. It's not much of a Web when you don't have any depth... it's more of two intertwined strands then ;). HTH, Peter. PS: My ownertrust for E is useless for now, because he/she is at level 5. However, if I get a shorter path to him or her later, it will become useful then. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
On 11/07/2013 11:09 AM, Leo Gaspard wrote: Except they do not have to know X, nor that he makes perfectly reasonable decisions in signing keys. And I believe it's not noise. Let's make an example in the real world : * I would entrust X with my life * X would entrust Y with his life, without my knowing it * Thus, if I actually entrusted X with my life, why should I be frightened if X asked Y to take care of me ? Provided, of course, X told me he was letting Y take care of me. After all, I would entrust X with my life, so I should just agree to any act he believes is good for me. (That's what I called blind trust. Somewhat more than full trust, I believe.) if we're talking about gpg's concept of ownertrust, please do not muddy the waters with entrust X with my life? gpg's ownertrust is much more narrow than that: it says I am willing to rely on OpenPGP certifications made by the holder of this key. entrust with my life is not simply a superset of all other trust. I have friends who would take care of me if i was deathly ill. I would place my life in their hands. But they have never thought about how to do rigorous cryptographic identity certification, and I would not rely on their OpenPGP certifications. Let's get back to ownertrust: in the Web of Trust, ownertrust is an expression of how well you think other people verify identities before they sign a key. If you sign key K2 based on X's signature, you haven't verified Y's identity. You've probably verified X's identity, but not Y's. So you shouldn't sign K2. So, is a signature a matter of belief in the validity of the key or of actual work to verify the key ? An OpenPGP certification says I believe that Key X belongs to the person identified by User ID U. Most people would not want to make that statement publicly without having thought about it and convinced themselves somehow that it is true. What it takes to convince each person may well vary, which is why we assign different ownertrust to different people. When making a public assertion like an OpenPGP certification, it is also probably reasonable to ask what the parties involved (or the rest of the world) gains from making that statement. Just because you believe a statement to be true doesn't mean you need to make it publicly, with strong cryptographic assurances, and it may have bad consequences. Also, consider that certifications are not necessarily forever. If Alice relies solely on Carol's certification to believe that key X belongs to Bob, and Alice then certifies (Bob,X), what does Alice do if Carol revokes her certification? If Alice doesn't pay attention and revoke her own certification, then she is announcing as fact to the world something that she should no longer believe to be true (assuming that she was relying only on Carol's certification for that belief). This sounds like an untenable maintenance situation I personally would rather avoid, which is why i do not make public certifications based solely on other people's certifications. If I understood correctly, the depth parameter you are talking about is useless, except in case there are trust signature. And you agreed with me for them to be taken out of the equation. The depth parameter is useful even without trust signatures. Peter Lebbings response upthread describes the scenario. Regards, --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
On Thu, Nov 07, 2013 at 07:21:28PM +0100, Peter Lebbing wrote: On 2013-11-07 17:09, Leo Gaspard wrote: If I understood correctly, the depth parameter you are talking about is useless, except in case there are trust signature. And you agreed with me for them to be taken out of the equation. Of course it's not useless. You seem to misunderstand the Web of Trust. I'll give an example. I know and trust the people A, B, C, D and E. A has signed B, B has signed C, C has signed D, D has signed E, and E has signed F. I meet up with A, verify their identity, and sign their key. I assign ownertrust to A, B, C, D and E. Et voilà, the keys A, B, C, D and E are all valid, without me needing to meet up with my other friends to verify their key details. A is at level 1, B at 2, C at 3, D at 4, and E at 5. Unfortunately, F won't get valid because it is at level 6. Indeed, I never thought someone would assign ownertrust without verifying the key. Please accept my apologies. However, I still believe that, under the condition any ownertrusted key has been verified (which, I assumed, was commonplace, but I was apparently wrong), the depth parameter is useless. Now suppose C signs F as well. F is now at level 4, so it becomes valid. However, I don't trust F, so even if F now signs G, G won't become valid. Signatures indicate verification, not trust or belief. Trust is in your trust database or in trust signatures, but the latter are not commonly used. Belief is expressed in validity calculated from your trust database and signatures. I don't know if you can choose to disagree with GnuPG, that is, if you don't believe a key is valid even though GnuPG calculated that it is. I'm sorry, I think I gave too much importance to your earlier statement (Signing is to be an attestation to the validity of the key.), incorrectly deducing from it that signatures indicates that you should sign whenever you believe a key is correct as much as if you met in person I could get back to all the other points you raise, but I think it's a waste of time when you have reasoned from the standpoint that to get a key to be valid, you need to sign it, and that is how it looks to me. It's not much of a Web when you don't have any depth... it's more of two intertwined strands then ;). I think this time, you gave too much importance to some of my sentences. Or maybe was I too bad at making myself understood. Anyway, I meant I should sign a key whenever I believe a key to be valid as much as if I met with the keyowner. Which, of course, does not equates with merely believing a key is valid. Indeed, on the WoT, one is rarely sure of the quality of signatures. (Indeed, I believe(d) full ownertrust must be quite rare., for that same reason ; but I am probably wrong.) And, now I know assigning ownertrust to not-personnally-checked keys is relatively common, I know I should not sign keys based on other people's verification. However, to come back to the initial problem, I still believe the key change problem (ie. owner of K1 switchs to K2) does not require re-verifying ownership etc. (BTW, isn't this also why transition statements, like https://we.riseup.net/assets/77263/key%20transition were written ?) But I still wonder how one should deal with key duplication (ie. owner of K1 now has a second key K2)... HTH, Peter. PS: My ownertrust for E is useless for now, because he/she is at level 5. However, if I get a shorter path to him or her later, it will become useful then. Anyway, thanks for you detailed explanations about the WoT ! Cheers, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
On Thu, Nov 07, 2013 at 01:40:22PM -0500, Daniel Kahn Gillmor wrote: On 11/07/2013 11:09 AM, Leo Gaspard wrote: Except they do not have to know X, nor that he makes perfectly reasonable decisions in signing keys. And I believe it's not noise. Let's make an example in the real world : * I would entrust X with my life * X would entrust Y with his life, without my knowing it * Thus, if I actually entrusted X with my life, why should I be frightened if X asked Y to take care of me ? Provided, of course, X told me he was letting Y take care of me. After all, I would entrust X with my life, so I should just agree to any act he believes is good for me. (That's what I called blind trust. Somewhat more than full trust, I believe.) if we're talking about gpg's concept of ownertrust, please do not muddy the waters with entrust X with my life? gpg's ownertrust is much more narrow than that: it says I am willing to rely on OpenPGP certifications made by the holder of this key. entrust with my life is not simply a superset of all other trust. I have friends who would take care of me if i was deathly ill. I would place my life in their hands. But they have never thought about how to do rigorous cryptographic identity certification, and I would not rely on their OpenPGP certifications. Indeed, I thought of this case after having sent my email. Anyway, by blind trust, I did mean a superset of all trusts related to keysigning. Let's get back to ownertrust: in the Web of Trust, ownertrust is an expression of how well you think other people verify identities before they sign a key. If you sign key K2 based on X's signature, you haven't verified Y's identity. You've probably verified X's identity, but not Y's. So you shouldn't sign K2. So, is a signature a matter of belief in the validity of the key or of actual work to verify the key ? An OpenPGP certification says I believe that Key X belongs to the person identified by User ID U. Most people would not want to make that statement publicly without having thought about it and convinced themselves somehow that it is true. What it takes to convince each person may well vary, which is why we assign different ownertrust to different people. When making a public assertion like an OpenPGP certification, it is also probably reasonable to ask what the parties involved (or the rest of the world) gains from making that statement. Just because you believe a statement to be true doesn't mean you need to make it publicly, with strong cryptographic assurances, and it may have bad consequences. Also, consider that certifications are not necessarily forever. If Alice relies solely on Carol's certification to believe that key X belongs to Bob, and Alice then certifies (Bob,X), what does Alice do if Carol revokes her certification? If Alice doesn't pay attention and revoke her own certification, then she is announcing as fact to the world something that she should no longer believe to be true (assuming that she was relying only on Carol's certification for that belief). This sounds like an untenable maintenance situation I personally would rather avoid, which is why i do not make public certifications based solely on other people's certifications. Indeed. I just backed off in my answer to Peter, by understanding why it was not needed. However, I believe that for the initial problem (ie. key change), information provided by a signed message accompanied from a UID on the other key is significant enough, and moreover definite, so I would not be bothered signing such a new key (of course, also revoking the signature on the old key). If I understood correctly, the depth parameter you are talking about is useless, except in case there are trust signature. And you agreed with me for them to be taken out of the equation. The depth parameter is useful even without trust signatures. Peter Lebbings response upthread describes the scenario. Indeed. Thanks for your answer, clarifying once again what signatures mean ! (I know, I'm slow to understand, but I think I'm OK no.) Cheers, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
On Thu, Nov 07, 2013 at 08:10:11PM +0100, Leo Gaspard wrote: I'm sorry, I think I gave too much importance to your earlier statement (Signing is to be an attestation to the validity of the key.) [...] Sorry again, just noticed it actually wasn't you statement, but Paul's ! So, double mistake... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
question about public key usage
Hi Is it possible to have 2 public keys with different expiration dates for the same user? I created a public key a couple of years ago to be used to exchange documents with vendors for a batch processing account. That is working just fine. A new vendor wants our public key but requires the key to have a shorter expiration date. I don't want to distribute a new public key to existing customers. Thank you. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone: 509.375.2687 Fax:509.375.2330 Email: cathy.sm...@pnnl.gov ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: question about public key usage
Thank you The earlier answer got caught at the firewall. I apologize for posting twice. Best regards, Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Operated by Battelle for the U.S. Department of Energy Phone: 509.375.2687 Fax: 509.375.2330 Email: cathy.sm...@pnnl.gov -Original Message- From: Doug Barton [mailto:do...@dougbarton.us] Sent: Thursday, November 07, 2013 12:57 PM To: Smith, Cathy; 'gnupg-users@gnupg.org' Subject: Re: question about public key usage On 11/07/2013 12:52 PM, Smith, Cathy wrote: Hi Is it possible to have 2 public keys with different expiration dates for the same user? I created a public key a couple of years ago to be used to exchange documents with vendors for a batch processing account. That is working just fine. A new vendor wants our public key but requires the key to have a shorter expiration date. I don't want to distribute a new public key to existing customers. Someone else already answered this question for you, but the answer effectively is yes, however you don't need to do that. Edit the expiration date on the existing key to match the requirement for the new vendor, and then give them that version of the key. There is no reason to have multiple keys in this situation. hope this helps, Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm and expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 7 November 2013 at 11:16:36 AM, in mid:87txfotqaz@gilgamesch.quim.ucm.es, Uwe Brauer wrote: BTW, I see you switched back to pgp, but why do you use old inline mode and not pgpmine? Because I prefer it. I like to see the pgp signature in the message body instead of hidden away. - -- Best regards MFPAmailto:expires2...@ymail.com Those who do not read are no better off than those who cannot. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlJ8BO5XFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5psUsD/iQhZWfXfzbDmVs/8vNg4nFRIZ5IXTb3LRU9 MbiKAdH6V6p55PMQ8/z/qJHBXHbnhacnKUMXPvyK71w5kKAnWb2gZfJivJj36axI h0btBJjCA3d2899fuODBdON1y+q/VgZLfMA5Uj1ILN9AC8SnDrUHUqGDHzeH1xZm OMbGJVaC =5KUo -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: question about public key usage
On 11/07/2013 01:02 PM, Smith, Cathy wrote: Thank you The earlier answer got caught at the firewall. I apologize for posting twice. Np, it happens. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Signing keys on a low-entropy system
Hi, I'm currently thinking about using a raspberry pi as a non-networked stand- alone system for signing keys. Since I haven't heard anything to the contrary, I'm pretty sure that entropy is relatively scarce on the pi. How is GnuPG affected by such a low-entropy system? Will operations just take a bit longer, or can this affect the quality/security of generated keys or signatures? I heard that low entropy or a bad entropy source is generall less of a problem for RSA. Is this true? Does this affect me in practice? Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing keys on a low-entropy system
(Failed again to answer to list. I really ought to replace this shortcut...) On Fri, Nov 08, 2013 at 12:11:38AM +0100, Johannes Zarl wrote: Hi, I'm currently thinking about using a raspberry pi as a non-networked stand- alone system for signing keys. Since I haven't heard anything to the contrary, I'm pretty sure that entropy is relatively scarce on the pi. I heard haveged is quite good at gathering entropy from anywhere it can (processor cycles, etc.) How is GnuPG affected by such a low-entropy system? Will operations just take a bit longer, or can this affect the quality/security of generated keys or signatures? I heard that low entropy or a bad entropy source is generall less of a problem for RSA. Is this true? Does this affect me in practice? In theory, if /dev/random is configured to allow only random enough data to pass, it should just mean operations would just take longer. However, I am not absolutely sure of this -- but I know in theory /dev/random ensures some minimum entropy, thus sometimes blocking reads. Cheers HTH, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm and expired certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 7 November 2013 at 11:16:36 AM, in mid:87txfotqaz@gilgamesch.quim.ucm.es, Uwe Brauer wrote: However it is not necessary I just export our signature as a pem file and import in under authorities. Still this is very uncomfortable... I had to search for and import some more root certificates from the Comodo website before I could encrypt to you using my mailer's built-in s/mime. Microsoft Crypto-API no use, even after your and comodo's certificates imported into certmgr.msc. I'm probably doing something wrong there, but it's not clear what to do. For something that is supposed to be easier than OpenPGP, s/mime doesn't seem easy to me. - -- Best regards MFPAmailto:expires2...@ymail.com My mind works like lightning... one brilliant flash and it's gone -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlJ8IW9XFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p2hIEAJuUrJYztL/8jLXZ525+nGHHzIkKtXDUOTDn o1DtWyAYMd0UDhAaJsK4aZl5KeiyP+AwjPSAtQExFwz8pg4ywhMx0SUC/3PcmmEs BlxHRXOhf31d71ndv0gTu1XFVi/2N1dfXZSlI4DO0iOICgnNqIWubwsxkuA8zzBd 3q/j95// =V2Ln -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 7 November 2013 at 7:10:11 PM, in mid:20131107191011.GF470@leortable, Leo Gaspard wrote: But I still wonder how one should deal with key duplication (ie. owner of K1 now has a second key K2)... If the owner doesn't revoke one, you could always disable one. One approach might be to contact the owner and ask which key to use. Or use the newest available key. Or just pick at random. Or encrypt to both. Or use whichever the owner seems to use themself. But they might have multiple keys for a reason, such as purpose of communication. Or one for their phone and another for their computer. - -- Best regards MFPAmailto:expires2...@ymail.com Volvo, Video, Velcro. (I came, I saw, I stuck around.) -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlJ8KGhXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pP6QEALCiKSGC/EnSauln6vySoDer3fua90MUrsGN ymE70UZ/f7tpe2GfPt7pMiMoLxXubxKXWRK0soSDk77E+FoQlN98jMVt9pwrd+dZ BFvlIXCJHyIQml4njLn9cOtlnAqY4MAMkPKVMEbTNQOChZRokQylQIFfby4M+D7v J6nj6a8O =vTwh -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: unsubscribe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 6 November 2013 at 7:46:50 AM, in mid:aa96def1c0ebc54d989e760702dcae32013f23c9a...@stfmsx01.staff.cpce.hk, Griffin Cheng [CLIB] wrote: [nothing] I thought subscribe and unsubscribe and help requests went to gnupg-users-requ...@gnupg.org - -- Best regards MFPAmailto:expires2...@ymail.com If you are afraid to speak against tyranny, then you are already a slave. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlJ8KVVXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p5dcD/2dPvtp9IU1WQfDKDIyjHk9G4yn3pj7dLglH y9+oGbrBouymtRIA+sNiN67XobrZn3iFzsb3XdKYddTrda/T1ST+qZdR0TY8CGjo lr0jnSvVgXqdobo2rOjfu7hg9BIa4pH85jtzyAuq1uy2yuUuiV0f+gKxkToA2Wxd aJmk7s3y =pY0R -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
