Re: Best practice for periodic key change?
On Tue, May 10, 2011 at 07:42, Grant Olson k...@grant-olson.net wrote: On 5/10/2011 1:35 AM, Jerome Baum wrote: AFAIK, the CAs over here will just supply a card. There is no question of whether the key is generated on-card or not -- the CA confirms this implicitly with their certification of this is a valid signing key per applicable signature laws. Okay, yeah, if the CA sets up the card, authenticates it with their signing key, and ships it to you, then there would never be a separate master key, no problem there. I get the feeling the card won't like it if you try to create a software signing key, but I'm not sure how that will work. I do have a spare card here if you want me to test this. I see no possibility, from a theoretical perspective, of signing only on-card keys (per signature laws) from a distance -- apart from some other secret stored on the card. In either case, the CA needs to initialize the card itself. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Tue, May 10, 2011 at 07:42, Grant Olson k...@grant-olson.net wrote: Okay, yeah, if the CA sets up the card, authenticates it with their signing key, and ships it to you, then there would never be a separate master key, no problem there. I get the feeling the card won't like it if you try to create a software signing key, but I'm not sure how that will work. I do have a spare card here if you want me to test this. Oh, and yes please do test it -- practical results are helpful. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Am Dienstag, 10. Mai 2011, 07:10:42 schrieb Jerome Baum: an option for GnuPG: reject-subkey-signatures No need to change OpenPGP for this. This is possible only if it is safe for old implementations. I see one option for that: A signature notation for this purpose could be defined and this notation could be marked critical. The standard says: If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error. I don't understand whether this refers to the packet type or the packet content. If an implementation knows what a notation is (and shows it) but does not know the meaning of the new standardized notation what is it supposed to do according to RFC 4880? Generate an error saying I don't understand what this notation is about or signal success saying I recognize this as a notation. (And I don't care about its content.)? If the recognition refers to the content then it's easy. There would be the practical problem left to check how the (relevant) implementations behave. It's no use if you are theoretically right but it is trivial to trick people into acceptance of wrong signatures because an often used software does not work right. A safe solution should be to define a new packet type. That might be a generic notation with critical content type. This would behave like a notation with the difference that the recognition check is extended to the content (if this packet is marked critical?). But if the standard is extended then it makes more sense to have subkeys certified explicitly instead of forbidding the acceptance of normal subkeys in general. The CA would then sign the master key that is generated on-card, and the certification just won't apply to the sub-keys. Does this solve the all signatures _must_ be generated on-card issue? In theory. The practice problem remains: Do all implementations behave that way. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
I don't see why it would need a standards change, or why the option can't be, well, optional. We aren't trying to force all gpg installations to conform, but to make it possible to configure an installation to conform. Normal gpg should continue to function. (Mobile/Handy) Am 10.05.2011 15:33 schrieb Hauke Laging mailinglis...@hauke-laging.de: Am Dienstag, 10. Mai 2011, 07:10:42 schrieb Jerome Baum: an option for GnuPG: reject-subkey-signatures No need to change OpenPGP for this. This is possible only if it is safe for old implementations. I see one option for that: A signature notation for this purpose could be defined and this notation could be marked critical. The standard says: If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error. I don't understand whether this refers to the packet type or the packet content. If an implementation knows what a notation is (and shows it) but does not know the meaning of the new standardized notation what is it supposed to do according to RFC 4880? Generate an error saying I don't understand what this notation is about or signal success saying I recognize this as a notation. (And I don't care about its content.)? If the recognition refers to the content then it's easy. There would be the practical problem left to check how the (relevant) implementations behave. It's no use if you are theoretically right but it is trivial to trick people into acceptance of wrong signatures because an often used software does not work right. A safe solution should be to define a new packet type. That might be a generic notation with critical content type. This would behave like a notation with the difference that the recognition check is extended to the content (if this packet is marked critical?). But if the standard is extended then it makes more sense to have subkeys certified explicitly instead of forbidding the acceptance of normal subkeys in general. The CA would then sign the master key that is generated on-card, and the certification just wo... In theory. The practice problem remains: Do all implementations behave that way. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Am Sonntag, 8. Mai 2011, 14:50:36 schrieb MFPA: Mainly the key's owner, but could also protect others from relying on signatures from a compromised key for which they have not received a revocation certificate. Right. The problem: Protection you don't know of. So seriously this additional protection will not be taken into account (unless you happen to have more information about the key handling). Could a modified version of HOW TO MIGRATE A (SUB)KEY INTO A NEW KEY http://atom.smasher.org/gpg/gpg-migrate.txt be used to substitute one of your subkeys with another of the same type and size? Or what would be the implications of an attacker migrating your subkeys to another master key? That would be useless. The result would be that the attacked user (if he had imported the master key with the migrated subkey) would believe that a signature has been made by the attacker instead of the person whom he has stolen the key from. If an attacker wants somebody to believe that he has made a signature than he can trivially make one. No need to steal keys for that. When encrypting there would be no difference if you don't address the subkey directly but the main key or one of the UIDs. And as I am dreaming: With a notation for identifying all subkeys (thus extending a certification from UIDs to subkeys) the first hurdle for getting GnuPG / OpenPGP compliant with German signature law (at least on the theoretical level) would be taken. Would that mean a certification of a particular UID on a key was not valid in conjunction with subkeys that were not present on the copy of the key you signed? Yes. That were not present or not signed. Like with UIDs. If so, wouldn't that discourage people from using short-life subkeys because they would need to obtain signatures on new ones? Or have I misunderstood? That is correct but there would be no need for short-life subkeys any more. The problem is that German / EU signature law requires a legally fully trusted key to be created in hardware which he can never be read from. So the so called qualified signatures can be made with smartcards only. Thus the certification authorities are not allowed so certify today's mainkeys because you can create valid subkeys outside smartcards with them without the CA being part of that. IMHO there are only two possibilities for making (a new version of) OpenPGP signature law compatible: a) The CA creates a mainkey and subkeys. The mainkey is destroyed immediately afterwards. That might be legally acceptable but has not much in common with PGP any more. b) It is made possible to prevent the transfer of the validity of a mainkey to a subkey. Either my disallowing subkeys at all (in the certification) or by requiring explicit certifications for subkeys. When certifying a key you would have to decide whether you make a certification of the old type (for the mainkey and then the mainkey is allowed to do everything) or of the new one. This new type of certification would not be allowed to be backward compatible. if it was then old software might regard an explicit subkey certification as a normal one and thus accept subkeys without explicit certification. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 9 May 2011 at 5:09:00 PM, in mid:201105091809.05423.mailinglis...@hauke-laging.de, Hauke Laging wrote: Am Sonntag, 8. Mai 2011, 14:50:36 schrieb MFPA: Mainly the key's owner, but could also protect others from relying on signatures from a compromised key for which they have not received a revocation certificate. Right. The problem: Protection you don't know of. So seriously this additional protection will not be taken into account (unless you happen to have more information about the key handling). I meant the protection other users derive because the compromised subkey expired and the attacker cannot keep making signatures with it. Could a modified version of HOW TO MIGRATE A (SUB)KEY INTO A NEW KEY http://atom.smasher.org/gpg/gpg-migrate.txt be used to substitute one of your subkeys with another of the same type and size? Or what would be the implications of an attacker migrating your subkeys to another master key? That would be useless. The result would be that the attacked user (if he had imported the master key with the migrated subkey) would believe that a signature has been made by the attacker instead of the person whom he has stolen the key from. Could that be a form of attack? Bob and Mallory sign a contract of some kind - it transpires the contract benefits Bob - Mallory tries to make it look as if Bob had not signed. The problem is that German / EU signature law requires a legally fully trusted key to be created in hardware which he can never be read from. So the so called qualified signatures can be made with smartcards only. Thus the certification authorities are not allowed so certify today's mainkeys because you can create valid subkeys outside smartcards with them without the CA being part of that. Sounds like vested interests calling the shots. IMHO there are only two possibilities for making (a new version of) OpenPGP signature law compatible: There is a third way: amend the law so that the Web of Trust is used instead of the CAs. - -- Best regards MFPAmailto:expires2...@ymail.com Look, it's a hat! It's not going to hurt you. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNyCmZnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5po0AD/iuB L6eK+ZSvFteIFxU1cMg6iEPAzKQNuRA9AheQtKUox/cTEoIPLx0MUpZuRP+JWy86 8VUe5TytuDuFilz5dC7VQOofZfVfyp5pJMWBeO/aJ/wLvBtL20ty4jyk8pwjeA6H Uf/2x/qil1p881Bgv9VkW8j/RQQH4rkUyT1Z9Fcz =qWQU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Am Montag, 9. Mai 2011, 19:51:12 schrieb MFPA: Could that be a form of attack? Bob and Mallory sign a contract of some kind - it transpires the contract benefits Bob - Mallory tries to make it look as if Bob had not signed. That would not work for several reasons which arise not from technical aspects but the circumstances: a) Usually the contract mentions the partners. Mallory would have to claim that somebody else had signed that though that obviously does not make any sense. Furthermore this other one would deny that. b) It would be obvious that the secret key of the subkey has been stolen. That would be a huge risk for the one who has stolen it. He would have to stand up in public and state: Only two people can have stolen the key. One of them is me. I am not experienced with criminals but I really doubt that this sounds interesting to them. c) Mallory cannot have created signatures before he stole the key. Bob usually has created a lot. Everyone who claims to have seen a signature of the key in question by Mallory before the (probably unknown) date of theft is at serious risk to be proven to have lied in court. This would be possible with very new keys only. There is a third way: amend the law so that the Web of Trust is used instead of the CAs. This is not about the source of trust IMHO. I think that the major aim of the law is to prevent the stealing of keys because that would reduce the trust in digital signatures in an amount a modern society cannot afford. Thus the law requires hardware protection. Whether a hardware-protected key is certified by a CA or (strongly enough) by a WoT is less important. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
On Mon, May 9, 2011 at 18:09, Hauke Laging mailinglis...@hauke-laging.dewrote: IMHO there are only two possibilities for making (a new version of) OpenPGP signature law compatible: a) The CA creates a mainkey and subkeys. The mainkey is destroyed immediately afterwards. That might be legally acceptable but has not much in common with PGP any more. b) It is made possible to prevent the transfer of the validity of a mainkey to a subkey. Either my disallowing subkeys at all (in the certification) or by requiring explicit certifications for subkeys. When certifying a key you would have to decide whether you make a certification of the old type (for the mainkey and then the mainkey is allowed to do everything) or of the new one. This new type of certification would not be allowed to be backward compatible. if it was then old software might regard an explicit subkey certification as a normal one and thus accept subkeys without explicit certification. c) Program the smart-card so it doesn't sign sub-keys? I'm not familiar with the internals of smart-card implementations but the OpenPGP sub-key signatures are of a different type than the data signatures. The smart-card can probably recognize if it's inadvertently signing a sub-key. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/10/2011 12:01 AM, Jerome Baum wrote: c) Program the smart-card so it doesn't sign sub-keys? I'm not familiar with the internals of smart-card implementations but the OpenPGP sub-key signatures are of a different type than the data signatures. The smart-card can probably recognize if it's inadvertently signing a sub-key. I doubt it -- the bytestring signed during OpenPGP key+userid certifications has a different prefix than the bytestring signed during a data signature. But i think the data signed by a hardware implementation is a digest of the bytestring, not the bytestring itself. I don't think a smartcard would be able to tell the prefix of the underlying bytestring from the digest it receives as a signature request. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/10/2011 12:32 AM, Jerome Baum wrote: Is that an implementation problem? i.e. is it possible to write an implementation that does distinguish, or is it technically impossible w/out processing the entire data on-card? As i understand the process, i think it would be necessary to pass all the data through the card in order to for the card to know which type of signature it was making. I know nothing of the details of how these cards are implemented, though. Maybe they do this already? it seems like performance would be problematic if you were signing something like a multi-MiB document, given the speed of most smartcards. Maybe one of the folks with experience implementing these devices can give more concrete details? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 5/10/2011 12:41 AM, Daniel Kahn Gillmor wrote: On 05/10/2011 12:32 AM, Jerome Baum wrote: Is that an implementation problem? i.e. is it possible to write an implementation that does distinguish, or is it technically impossible w/out processing the entire data on-card? As i understand the process, i think it would be necessary to pass all the data through the card in order to for the card to know which type of signature it was making. I know nothing of the details of how these cards are implemented, though. Maybe they do this already? it seems like performance would be problematic if you were signing something like a multi-MiB document, given the speed of most smartcards. Maybe one of the folks with experience implementing these devices can give more concrete details? --dkg I can confirm. The cards only get the hash and sign that. The trouble is the the smart cards are pretty dumb by modern standards. They don't actually know much about OpenPGP itself, they basically just do RSA signing, encryption, and decryption. gpg passes the minimal operations off to the card in very simple APDU commands. The smartcard spec itself doesn't even acknowledge the difference between a certification sig vs a normal sig. And even with a valid smart-card, you still need to retrieve the public key from the keyservers when setting up your card. The whole public key is just too much info to store on the card. This is pure speculation on my part, but now that the chip-cards aren't that powerful, and the even less powerful contact-less smart-cards are becoming more popular, I don't expect the standard to get much more sophisticated in the near future. Maybe ECC gets added in the new spec, but I can't see the stuff you guys are talking about hitting the 3.0 standard. -- Grant signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Tue, May 10, 2011 at 07:01, Grant Olson k...@grant-olson.net wrote: On 5/10/2011 12:41 AM, Daniel Kahn Gillmor wrote: Maybe one of the folks with experience implementing these devices can give more concrete details? I can confirm. The cards only get the hash and sign that. The trouble is the the smart cards are pretty dumb by modern standards. They don't actually know much about OpenPGP itself, they basically just do RSA signing, encryption, and decryption. gpg passes the minimal operations off to the card in very simple APDU commands. The smartcard spec itself doesn't even acknowledge the difference between a certification sig vs a normal sig. And even with a valid smart-card, you still need to retrieve the public key from the keyservers when setting up your card. The whole public key is just too much info to store on the card. This is pure speculation on my part, but now that the chip-cards aren't that powerful, and the even less powerful contact-less smart-cards are becoming more popular, I don't expect the standard to get much more sophisticated in the near future. Maybe ECC gets added in the new spec, but I can't see the stuff you guys are talking about hitting the 3.0 standard. So given that, I guess we could still distinguish between a master key signature and a sub-key signature, to conform w/ signature laws? e.g. an option for GnuPG: reject-subkey-signatures -- then an installation w/ this option set would validate only master key signatures, practically forbidding signing sub-keys. No need to change OpenPGP for this. The CA would then sign the master key that is generated on-card, and the certification just won't apply to the sub-keys. Does this solve the all signatures _must_ be generated on-card issue? -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 5/10/2011 1:10 AM, Jerome Baum wrote: On Tue, May 10, 2011 at 07:01, Grant Olson k...@grant-olson.net mailto:k...@grant-olson.net wrote: On 5/10/2011 12:41 AM, Daniel Kahn Gillmor wrote: Maybe one of the folks with experience implementing these devices can give more concrete details? I can confirm. The cards only get the hash and sign that. The trouble is the the smart cards are pretty dumb by modern standards. They don't actually know much about OpenPGP itself, they basically just do RSA signing, encryption, and decryption. gpg passes the minimal operations off to the card in very simple APDU commands. The smartcard spec itself doesn't even acknowledge the difference between a certification sig vs a normal sig. And even with a valid smart-card, you still need to retrieve the public key from the keyservers when setting up your card. The whole public key is just too much info to store on the card. This is pure speculation on my part, but now that the chip-cards aren't that powerful, and the even less powerful contact-less smart-cards are becoming more popular, I don't expect the standard to get much more sophisticated in the near future. Maybe ECC gets added in the new spec, but I can't see the stuff you guys are talking about hitting the 3.0 standard. So given that, I guess we could still distinguish between a master key signature and a sub-key signature, to conform w/ signature laws? e.g. an option for GnuPG: reject-subkey-signatures -- then an installation w/ this option set would validate only master key signatures, practically forbidding signing sub-keys. No need to change OpenPGP for this. The CA would then sign the master key that is generated on-card, and the certification just won't apply to the sub-keys. Does this solve the all signatures _must_ be generated on-card issue? I haven't been totally following this thread, but... The card itself only has one Signature key slot. If you generate this key on-board, that will be both the certification key and the signing key. If you migrate a signing sub-key, you'll still have an offline master key. The card itself doesn't know if you have a signing subkey or not. It just knows, This is the signing key I use. If you generate all keys on-card, you only have a master Certification/Signing key, along with (optionally) one encryption and one authentication key. If you didn't generate the keys on-card, and have an offline master key, the card itself won't know about it, but the certificate will still imply that the on-card signing key isn't the master key, since the card only allows one signing key and don't know the difference. But there's no way to prove that the keys were originally generated on-card, and weren't imported from a software private key where there was never a separate master certification key. I think a 'generated on card' flag is something that you could probably fit into the constraints of a smart-card spec, if this is all you need. But at least in the US, you'd probably need some sort of certification/approval process (like the NIST lab) to demonstrate to the government that you're actually setting this flag correctly. The same way PGP Corp software has some government approvals that gpg will never have. -- Grant signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Tue, May 10, 2011 at 07:30, Grant Olson k...@grant-olson.net wrote: But there's no way to prove that the keys were originally generated on-card, and weren't imported from a software private key where there was never a separate master certification key. AFAIK, the CAs over here will just supply a card. There is no question of whether the key is generated on-card or not -- the CA confirms this implicitly with their certification of this is a valid signing key per applicable signature laws. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 5/10/2011 1:35 AM, Jerome Baum wrote: On Tue, May 10, 2011 at 07:30, Grant Olson k...@grant-olson.net mailto:k...@grant-olson.net wrote: But there's no way to prove that the keys were originally generated on-card, and weren't imported from a software private key where there was never a separate master certification key. AFAIK, the CAs over here will just supply a card. There is no question of whether the key is generated on-card or not -- the CA confirms this implicitly with their certification of this is a valid signing key per applicable signature laws. Okay, yeah, if the CA sets up the card, authenticates it with their signing key, and ships it to you, then there would never be a separate master key, no problem there. I get the feeling the card won't like it if you try to create a software signing key, but I'm not sure how that will work. I do have a spare card here if you want me to test this. -- Grant signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 8 May 2011 at 3:34:52 AM, in mid:201105080434.57614.mailinglis...@hauke-laging.de, Hauke Laging wrote: There is probability but no safety in this assumption. I have no idea what is the probability. I have seen no figures relating to what fraction of people using subkeys with expiry dates claim to keep their master keys offline. But it this relevant? This depends on whether/how the validity of the assumption affects your threat model. How and whom is an expiration date supposed to protect? Mainly the key's owner, but could also protect others from relying on signatures from a compromised key for which they have not received a revocation certificate. And what is the alternative?. I don't know. Expiry dates serve a purpose but cannot be relied upon, because system clock times/dates cannot be relied upon and a signature with a timestamp during the key's validity period is a valid openPGP signature. This may be addressed by using a trusted timestamp service. One might ask: Do users who observe expiration dates refresh their keyrings less often on average (due to false trust in the expiration feature)? Does it make sense for an attacker to replace non-expiring subkeys with expiring ones in order to reduce the refresh frequency of the ones being attacked by forged signatures? ;-) That's an interesting thought experiment. But there is security for the owner of the key. He knows that his mainkey is stored safely offline so that nobody will ever meet forged subkeys of this key. Thus he safely protects himself and his communication partners from the use of expired keys. Could a modified version of HOW TO MIGRATE A (SUB)KEY INTO A NEW KEY http://atom.smasher.org/gpg/gpg-migrate.txt be used to substitute one of your subkeys with another of the same type and size? Or what would be the implications of an attacker migrating your subkeys to another master key? As you may remember I promote both an implicit and an explicit solution of this problem (not knowing enough about others' key handling) here from time to time: [snipped] That is very thorough. If there was a standard for this GnuPG could be extended to allow for a configuration taking this into account. The extreme version: Trust certifications of others only if they are offline keys. That does seem extreme but it depends on the threat model. And as I am dreaming: With a notation for identifying all subkeys (thus extending a certification from UIDs to subkeys) the first hurdle for getting GnuPG / OpenPGP compliant with German signature law (at least on the theoretical level) would be taken. Would that mean a certification of a particular UID on a key was not valid in conjunction with subkeys that were not present on the copy of the key you signed? If so, wouldn't that discourage people from using short-life subkeys because they would need to obtain signatures on new ones? Or have I misunderstood? - -- Best regards MFPAmailto:expires2...@ymail.com Humility is no substitute for a good personality. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxpG8nhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pT7sEALNB lErOSpojvDTD7ngm22Q3IC5UvUmQy1cRnpJh6coShgROBNrCW6dDgOv39yi6/VH2 sNKM9LyqWt1XU+fhmVX/uS2nlFgh0VysYfyYjNs81bLSHmkYc771tZLl4jhK9zUf +GWXxe0AQ7hVukQcRbtT/tj23ThWdQNfSwroZO2O =Tuwx -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 8 May 2011 at 3:21:41 AM, in mid:4dc5fe35.5080...@sixdemonbag.org, Robert J. Hansen wrote: The trial court ruled in favor of the farmers. I remember literature from my bank saying that cheques did not need to be on their printed form so long as all the required details were included. Complete with cartoon illustrations, they cited examples of an oil drum, an egg, and a cow! They also warned they would levy additional handling charges... - -- Best regards MFPAmailto:expires2...@ymail.com Humility is no substitute for a good personality. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxpa2nhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p/Q8D/iSo iggYUCYhBJbA6IgJWcA+KOxA85mNUsbws2ztlOBcRLbF62IUeEXvDYF3vW7IpTSn TGCaTw7rwvAgPyMNUOIy2yGs5HDOFvzSDE0a68s/t2YbE6842on/ZhkFRzSyeZqL JvCWj+nA/OneHEuZzW0kL/J7hIqty9QQRM2l7crt =TbWB -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sat, May 7, 2011 at 04:33, Grant Olson k...@grant-olson.net wrote: On 5/6/2011 10:05 PM, Hauke Laging wrote: Several people have mentioned that a signature does not become invalid by expiration of the key. That is formally correct an describes the GnuPG behaviour. But with regard to content in such a case there has to be an additional proof that the signature has been made before the key expired. This is a formal rule in e.g. the German signature law. If you want to use legally accepted signatures for proving documents then you have to sign both the document and the old signature by a new key (i.e. one with a later expiration date) before the old key expires. I know nothing about German laws, but that just doesn't sound right to me. 1) I digitally sign a document saying I owe you money. The signing key has an expiration date. 2) Key expires. I do nothing. 3) The original document is invalidated. I no longer owe you money? Do realize that it is necessary to resign from a practical standpoint (while I don't agree about the implication to a signature from an expired sub-key, yes you can set back your system clock), plus it's not the document that makes you owe me money. You owe me the money and the document only testifies this. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sat, May 7, 2011 at 01:43, MFPA expires2...@ymail.com wrote: On Saturday 7 May 2011 at 12:11:06 AM, in mid:BANLkTimNq9nxpf23=pe2n0rr1stnh3a...@mail.gmail.com, Jerome Baum wrote: Say my sub-key expired yesterday. Today, you come up to me and ask me to sign something (say, a statement that I agree to specific contractual terms). Whoever is in possession of my sub-key cannot sign that document as at the time that the statement was made available to me for signing, the sub-key was already invalid. The timestamp of the signature proves nothing. It is merely the time on the system clock when the signature was made. The system clock may be correct or incorrect; in your scenario above, it looks like you set it deliberately a day behind in an attempt to generate plausible deniability for your signature. Then I would say it is the recipients responsibility to only accept reasonable signatures. As you say, it is only an attempt to generate deniability -- nobody who's right in their mind would accept a signature on a document that is dated before the document itself. Assuming a responsible recipient, the expiration date makes sense. Yes, a responsible recipient would refresh their keys. Yes, man-in-the-middle. The expiration date makes a difference here. MPFA wrote: OK, when was this message signed? When was it sent? When did the server receive it? Exactly my point. The three timestamps are different (actually, there is a fourth time, though not timestamp -- there's when was this message signed and when was this message allegedly signed). When it was sent and when it was received wasn't what I meant with the date of the message. That date is when it was signed. But I have no idea of knowing when it was signed, so I have to assume it is when it was allegedly signed -- and yes, this is a problem under certain circumstances. However, there is at least one circumstance where the expiration date *does* make a difference, which is the document dated in the future relative to the signature timestamp, from a then-already expired key. So in at least one case, the expiration date helps. It is also not very expensive to have an expiration date. That was my argument for usefulness. Let's get a concrete idea of such a document. Say I want a statement from you that you legally have access to an email account today. Today is 2011-05-07. I have your key, with a signing sub-key that expired in 2010. I refresh your key but Mallory manipulates the traffic and so a revocation certificate wouldn't have helped. It's a good thing that your sub-key expired, though, because I won't accept the signature from that sub-key as I'm looking for an up-to-date statement. In fact, I'll probably want: As of 2011-05-07, I legally have access to em...@example.com. There is *no way* I would accept that when the signature is dated in 2010. Does that make my point more clear? I wasn't saying that under all circumstances the expiration date helps. That would be crazy. I was saying that there are circumstances where it does, and since the cost is so low, that there is no point in not having them (assuming, of course, that you separate master and sub-keys). -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 1:09:25 PM, in mid:banlktimpo-bwz38icrfc-cudrkh968f...@mail.gmail.com, Jerome Baum wrote: Then I would say it is the recipients responsibility to only accept reasonable signatures. Fair enough. Reasonable is subjective. As you say, it is only an attempt to generate deniability -- nobody who's right in their mind would accept a signature on a document that is dated before the document itself. In which case your attempt to generate plausible deniability would have fooled anybody who's right in their mind (because they all believe the signature timestamp has some meaning besides being the time/date your system clock happened to be set on when you created the signature). I'm not sure I buy that. Assuming a responsible recipient, the expiration date makes sense. Yes, a responsible recipient would refresh their keys. Yes, man-in-the-middle. The expiration date makes a difference here. In the edge-case scenario you described previously (where the key only expired the previous day) I doubt it would make much difference. Even the weak evidence of the email headers and server logs suggesting your system clock had been incorrectly set a day behind could be enough to make your deniability implausible. But I have no idea of knowing when it was signed, so I have to assume it is when it was allegedly signed That was exactly my point. -- and yes, this is a problem under certain circumstances. However, there is at least one circumstance where the expiration date *does* make a difference, which is the document dated in the future relative to the signature timestamp, from a then-already expired key. So in at least one case, the expiration date helps. A non-digital example of a document signed with a date in the future is the post-dated cheque, which is supposed to be worthless until the date written on it. Several people sent me cheques as wedding gifts, which they dated with our wedding day but we received them during the couple of weeks before. Most of those were banked the day after we received them, rather than waiting until we returned from our honeymoon. A bank clerk tried to refuse the last one I paid in on the Friday afternoon before our wedding but I persisted and he accepted it. The date in the future should have made a difference to those cheques but did not. (In the case of the last cheque that was queried, it made no difference because it would be the Monday two days *after* the date on the cheque that it was presented to the payee's branch for payment.) I suspect that fact of the signature timestamp and the key expiry date being before the date stated on the document, is something it would be unwise to rely upon in court. Especially if the other side produced an expert witness who testified about the triviality of altering a system clock. Let's get a concrete idea of such a document. Say I want a statement from you that you legally have access to an email account today. Today is 2011-05-07. I have your key, with a signing sub-key that expired in 2010. I refresh your key but Mallory manipulates the traffic and so a revocation certificate wouldn't have helped. It's a good thing that your sub-key expired, though, because I won't accept the signature from that sub-key as I'm looking for an up-to-date statement. In fact, I'll probably want: As of 2011-05-07, I legally have access to em...@example.com. There is *no way* I would accept that when the signature is dated in 2010. Several months out (because it expired last year) is different to your previous case of several hours out (because it expired yesterday). I could put the clock back exactly a year and some recipients may not spot one digit being different, but they are more likely to notice that than to notice the day being off (unless it occurs early in the new year before they have got used to spotting the year without thinking about it). Does that make my point more clear? I wasn't saying that under all circumstances the expiration date helps. That would be crazy. I was saying that there are circumstances where it does, It helps to raise a question in the mind of the person viewing the signature (if they spot it). and since the cost is so low, that there is no point in not having them (assuming, of course, that you separate master and sub-keys). You can't assume. - -- Best regards MFPAmailto:expires2...@ymail.com Life is a holiday. In the same way that glass is a liquid. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxU8TnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pvD8EAIA6 yHvGXM/rrzbfEpsGMptqQcVNOTFPgH8xxqdJpVrvlu1OYZ3OhHiW4kQV+vGVIzn6 SWci1bAJ3sI15o9cBIRIRoiA4lJhh7JBkgsoQ4o/ToS0QncD16cjZ46nyhPTFVfD
Re: Best practice for periodic key change?
Am Samstag, 7. Mai 2011, 15:54:21 schrieb MFPA: and since the cost is so low, that there is no point in not having them (assuming, of course, that you separate master and sub-keys). You can't assume. You can very well if you don't claim that for all cases but use this assumption for distinguishung between a useful and a useless use if expiration dates. AFAIR noone here on the list has claimed that it makes sense (with respect to security) to use key expiration dates without offline mainkeys. That is an important point in the discussion. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
On Sat, May 7, 2011 at 15:54, MFPA expires2...@ymail.com wrote: (snip huge email) Next time can you read the whole email and reply to it as a whole? As for signature checking, I stand by my point: Over here, signing a document today and claiming on the signature that it was signed tomorrow is going to be an offense (if there is a loss to a third party, of course -- a lie isn't fraud until there is damage). The post-dated cheque doesn't say I signed this in the future, but only accept this from that point in the future. That's a big difference. As for the clerk, he's an idiot and probably liable for accepting it. It's not my problem if people don't check the signature timestamp, I can only do my part on making the date accurate -- plus maybe educating my recipient on checking the timestamp. As for the expert witness, you can bring in an expert to claim anything. That doesn't change the facts and isn't relevant to this argument. You assumption on what a court would decide is the kind of assumption you said I can't make -- which, as Hauke points out, I didn't. As for months vs. years, I wanted a clear example. Doesn't really make a difference -- 1304780513 is different from 1304780514, and also different from 1404780513. What's your point? That the guy checking my signature is being careless by only checking the year? See the clerk point above. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Jerome Baum wrote: On Sat, May 7, 2011 at 15:54, MFPA expires2...@ymail.com mailto:expires2...@ymail.com wrote: (snip huge email) Next time can you read the whole email and reply to it as a whole? As for signature checking, I stand by my point: Over here, signing a document today and claiming on the signature that it was signed tomorrow is going to be an offense (if there is a loss to a third party, of course -- a lie isn't fraud until there is damage). The post-dated cheque doesn't say I signed this in the future, but only accept this from that point in the future. That's a big difference. As for the clerk, he's an idiot and probably liable for accepting it. It's not my problem if people don't check the signature timestamp, I can only do my part on making the date accurate -- plus maybe educating my recipient on checking the timestamp. When I was on a grand jury, the prosecutor said that while the words of the law made it illegal to write a post dated check (in this state), that they did not prosecute for this unless there was intent to commit a fraud, and that is difficult to prove. A friend who worked at a bank said they never looked at the dates, but cashed them when presented unless there were insufficient funds to honor them. So there is no use in writing a post dated check unless the person to whom it is presented holds on to it until the date. As treasurer of a tax deductible organization, I use the date on the check as the date of the donation except sometimes I do not. I do not when it is dated something late in December, but postmarked mid January or later. In that case, I use the postmark date. So people writing pre-dated or post-date checks are wasting their time. -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jerseyhttp://counter.li.org ^^-^^ 13:10:01 up 21 days, 16:28, 3 users, load average: 4.57, 4.78, 5.01 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[OT] Re: Best practice for periodic key change?
Hey not that any of this relates to the original question on digital signatures, but interesting nonetheless so I guess let's keep it on the list as OT. On Sat, May 7, 2011 at 19:16, Jean-David Beyer jeandav...@verizon.netwrote: When I was on a grand jury, the prosecutor said that while the words of the law made it illegal to write a post dated check (in this state), that they did not prosecute for this unless there was intent to commit a fraud, and that is difficult to prove. In that case we had a different understanding. Checks aren't common over here and I never saw a post-dated check -- which I assumed is a check that is meant to be available after a certain date -- not a check that is signed incorrectly. However if it is common practice to post-date checks, then it is reasonable not to prosecute as the date probably doesn't say I signed this check on the 5th but rather just 5. It's then a matter of interpretation, and common practice dictates interpretation here. I'd interpret it as I want this to be available after the 5th. Also see below about prosecution. A friend who worked at a bank said they never looked at the dates, but cashed them when presented unless there were insufficient funds to honor them. So there is no use in writing a post dated check unless the person to whom it is presented holds on to it until the date. It seems here that people who write post-dated checks the way you describe them don't quite understand what that particular date means (or I misunderstood you). What you describe is the signature date, and that date is *supposed* to be the date when you signed it. Using a different date is lying, but as you say it won't be prosecuted unless there is intended fraud or actual damage. It isn't usually illegal to lie (there may be specific exceptions e.g. checks), unless there is consequent damage. In fact, there are laws that explicitly allow lying even with consequent damage -- think anti-discrimination. As treasurer of a tax deductible organization, I use the date on the check as the date of the donation except sometimes I do not. I do not when it is dated something late in December, but postmarked mid January or later. In that case, I use the postmark date. Obviously can't tell about the situation elsewhere but the donation date is supposed to be the date when you received the donation. If it's a cashier's check -- which apparently aren't allowed over here -- then it's the date you received it (*maybe* postmark date). If it's a normal check, it would be the date you cashed it in. The (non-cashier's) check itself isn't the actual payment, it's just a paper slip that instructs the bank to do the payment. However, YMMV. So people writing pre-dated or post-date checks are wasting their time. Even if the checks had a field don't cash in until, I would still agree with you. At my bank, I left clear instructions on the deposit box card to require gov. ID for anyone trying to access my deposit box. The second time I accessed it (i.e. the first time after getting it) they were fine with just my key, didn't even ask for ID of any kind. I pointed it out and the clerk said oh, well it should be highlighted so we don't overlook it -- funny thing is, it's the only thing on the card besides access times, there is an ID column on the card as it's apparently common to require ID, and it was a clerk from the same branch who wrote it on the card originally. Overall banks are much more sloppy than I'd expect/hope them to be. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [OT] Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 6:42:06 PM, in mid:BANLkTi=-c_xijtne7+qyrlv06fj2d7z...@mail.gmail.com, Jerome Baum wrote: Hey not that any of this relates to the original question on digital signatures, but interesting nonetheless so I guess let's keep it on the list as OT. Since (like any other legal document) the date on a cheque is deemed to be the date of the signature, it is a non-digital analogy to the discussion about signature dates. In that case we had a different understanding. Checks aren't common over here and I never saw a post-dated check -- which I assumed is a check that is meant to be available after a certain date -- not a check that is signed incorrectly. You are entirely correct in your assumption. A friend who worked at a bank said they never looked at the dates, but cashed them when presented unless there were insufficient funds to honor them. That failure to correctly scrutinise is fairly common, and often allows people to cash cheques that have expired. It seems here that people who write post-dated checks the way you describe them don't quite understand what that particular date means (or I misunderstood you). What you describe is the signature date, and that date is *supposed* to be the date when you signed it. Using a different date is lying A cheque is an instruction to your bank to pay an amount of money to somebody if they present it for payment within six months of the date it was signed. In order to instruct the bank to pay within six months from a future date, you are simply preparing in advance an instruction effective from that future date. The date on the cheque is the date from which the signature is effective. It is non-standard but was very common when cheques were in widespread use. There is no lying, fraud or deception involved. , but as you say it won't be prosecuted unless there is intended fraud or actual damage. It is not illegal here, or even unlawful. I have heard of it being banned elsewhere but never heard a credible rationale as to why the practice should not be allowed. At my bank, I left clear instructions Giving clear instructions to a bank is usually a waste of time. They generally fail to carry them out correctly, in my experience. - -- Best regards MFPAmailto:expires2...@ymail.com A candle loses nothing by lighting another candle -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxZ9knhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pWuMEAJmX Qx6aFQywo49Dnsc/vk+HvWWEK2sPPNi+YRCcOrsA3XHygFGN7GAyv9udRfA8wLNJ IoRjMeqCp7lHL7Ls+FniwBeaJSHxaTfxDwxQH6nevmG0kMxJ6YdGHSM0mcx2IlrF 756TThZGwthh+mTSKd49ksmDYwJo7vdjfcb30dZZ =SVXo -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 4:03:19 PM, in mid:BANLkTi=ergk72zxrb46dwkc_dim0etg...@mail.gmail.com, Jerome Baum wrote: Next time can you read the whole email and reply to it as a whole? It's generally better to read the whole email and then reply to whichever points I have anything to say about. That way, it is fairly easy to follow the discussion. The post-dated cheque doesn't say I signed this in the future, but only accept this from that point in the future. That's a big difference. As for the clerk, he's an idiot and probably liable for accepting it. The (future) date on the cheque is simply the date from which the signed instruction to pay takes effect. It's not my problem if people don't check the signature timestamp, I can only do my part on making the date accurate -- plus maybe educating my recipient on checking the timestamp. Whether or not people check the signature timestamp, it still means nothing more than when I signed this, my signature clock was at this date/time. You assumption on what a court would decide is the kind of assumption you said I can't make -- which, as Hauke points out, I didn't. I made no such assumption, merely stated an opinion. As for months vs. years, I wanted a clear example. Doesn't really make a difference -- 1304780513 is different from 1304780514, and also different from 1404780513. What's your point? It was months vs hours. My point was that a few hours one way or the other, which was open to challenge in the light of the evidence about an incorrectly set system clock at the time the document was emailed back, was far less significant than a discrepancy of several months. Of course, the absence of any evidence that the system clock was correctly set when the signature was created makes the discussion a purely academic exercise. - -- Best regards MFPAmailto:expires2...@ymail.com If you can't convince them, confuse them. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxaeWnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p0JoEAIsV /vnmisrR/w52U8YqEJu78z1iTXyUqiKWELh9C39h0MQsD4uwiaqQ8BITVNXW7NjO e2i4iLYGZcN1rAGlRjrIZLX1TMXczqS40aQl4Pa/9btjCLkYxjPSOciVfXoIFTFs 6tdcPzP6tOyK31qKcPcoI/uwTuPyl4aboPu7AB7N =AN5H -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 3:06:16 PM, in mid:201105071606.21732.mailinglis...@hauke-laging.de, Hauke Laging wrote: Am Samstag, 7. Mai 2011, 15:54:21 schrieb MFPA: You can't assume. You can very well if you don't claim that for all cases but use this assumption for distinguishung between a useful and a useless use if expiration dates. AFAIR noone here on the list has claimed that it makes sense (with respect to security) to use key expiration dates without offline mainkeys. That is an important point in the discussion. At what point does it become safe to assume that an individual with expiry dates on their subkeys keeps their master key securely offline? - -- Best regards MFPAmailto:expires2...@ymail.com Raining cats and dogs is better than hailing taxis. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxaDynhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pdSUD/jTu kidc9dx/CxOkkkt9vmi2NEkctq66dBkVPFbeWPHOVwQNafWNh+tnG9t2JTdgfDJZ LP6TXw0tE8dJsNIXaZO4RfvQbtaYNqFVIVxd+jUoihAsROV+DYbAjrMv89lW2j9K mJS4835oQludvIqrXQ6Yaw5voqhWYvWnTGcDs8Qh =9FId -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 5/7/2011 7:54 AM, Hauke Laging wrote: Am Samstag, 7. Mai 2011, 04:33:17 schrieb Grant Olson: 1) I digitally sign a document saying I owe you money. The signing key has an expiration date. 2) Key expires. I do nothing. 3) The original document is invalidated. I no longer owe you money? Whether you owe me money does not depend on signing any documents in general. :-) Documents are usually just a proof. You can still claim that somebody owes you money but the document does not have the same legal value. What courts decide is another question... Yes, of course. But the fiscal authorities don't accept digital bills (probably the most frequent use of legally qualified signatures here) which are signed by expired keys only. You need a chain of signatures which prove that there was a non- expired signature at any point in time. For the same reason it makes sense to have digitally signed documents signed by another key (not just the document but the document together with the signature) at once when you get them. Because you cannot know whether and if a key will be revoked in the future. The moment it is revoked and you cannot prove the signatures being older than the revoke all signatures are dead. Okay, now I understand. It sounds like you're talking something like a digital notarization. That makes sense now. -- Grant signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [OT] Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 8:50:45 PM, in mid:BANLkTi=tg4z7mkwtnztwlhpjmhffznw...@mail.gmail.com, Jerome Baum wrote: We weren't talking about fraud and deception. Only about lying -- rather, telling an untruth, which you may or may not be doing intentionally. But it is still an untruth if the form implies that the date is the dated the signature was placed -- rather than an instruction to make the amount available after that date. Lying *is* deception. And your words unless there is intended fraud appeared to me to be a reference to fraud. As for the meaning of the date, whether it is supposed to mean the date the signature was written or the date the instruction to pay becomes effective or simply the date the cheque is issued to the payee is unclear to me - and probably varies around the world. UK banks have told me all three versions at various times. The one I heard originally (and most often over the years) is the effective date of the instruction to pay. YMMV. Are we OT enough yet? - -- Best regards MFPAmailto:expires2...@ymail.com During an eruption - move away from the volcano - not towards it -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxa3lnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p5tUD/23X qbYxg2mUvMtSE9xjGyn4ZybZI+cJstg/392D9Aqs8HQeIS9V7OQ34UHXPVZRngrS LKAS2gLJe3Zh4nBsuQfe4UhEzg4MNiPs9D8d7YQJ9gY9cecU7xyc48gp3pRyRGVb 02Acup6iPjqmCBbOd+Vcwq2h8l62uf6bomFGb3if =7P1o -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Friday 06 May 2011, MFPA wrote: Hi On Friday 6 May 2011 at 8:48:03 PM, in mid:201105062148.04...@thufir.ingo-kloecker.de, Ingo Klöcker wrote: Unless I'm missing something the difference is as follows: - With prolongation of the expiration time releases signed before the prolongation will keep having a valid signature. - If one creates a new subkey then releases signed with the old expired subkey(s) will have an invalid signature. One would have to re-sign the old releases with the new subkey. Surely the signature on the old release would still be valid; it would just be from a now-expired subkey instead of from the new and currently-valid subkey. Or have I overlooked something? It depends on your definition of valid. In my book a signature can only be valid if the corresponding key is valid. Expired keys are not valid (anymore). 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: [OT] Re: Best practice for periodic key change?
On Sat, May 7, 2011 at 22:47, Jerome Baum jer...@jeromebaum.com wrote: On Sat, May 7, 2011 at 22:38, MFPA expires2...@ymail.com wrote: As for the meaning of the date, whether it is supposed to mean the date the signature was written or the date the instruction to pay becomes effective or simply the date the cheque is issued to the payee is unclear to me - and probably varies around the world. UK banks have told me all three versions at various times. The one I heard originally (and most often over the years) is the effective date of the instruction to pay. YMMV. I would trust the fine print over any of these versions. That's what I meant with banks being incompetent. I might read through my fine print later to find out. If I do, I'll post here. Per Art. 1 Nr. 5 ScheckG (German law regarding checks), the date on the check is the date of issuing. Per Art. 28 there is no post-dating. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 9:52:51 PM, in mid:BANLkTi=nwtmcchq96olpkhdmovunsoq...@mail.gmail.com, Jerome Baum wrote: I don't think you get what kind of assumption we are talking about. There are two kinds: 1. I assume something is generally true, e.g.: I assume the world is around. 2. I assume something is true within this scope, so I don't have to restate the precondition with every statement I make, e.g.: assuming y z, and z x, we can follow that y x. It isn't really an argument to say you can't assume y z, so the point is invalid. I agree that in this specific instance we can assume y z. I do not agree that in general we can assume that an individual with expiry dates on their subkeys keeps their master key securely offline. - -- Best regards MFPAmailto:expires2...@ymail.com Don't ask me, I'm making this up as I go! -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxbSdnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pkxAD/Aoq p02FGwAMlU0hQX1GZPUeIhG1SOuCwWvj0OHJQNiJFJUE4hu6v8jlSoEpL6/YUk8N e2LTlTvjDwvf7KXPf5RDUtfC0EEQqo3CZYejAMDMerKS+9ni5b5oycerkoUHJ1Wu fpQLLB8wo6zp0MG8Ur8Thf+o5FlvohLoXP+zlTQx =BQFt -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sat, May 7, 2011 at 23:07, MFPA expires2...@ymail.com wrote: On Saturday 7 May 2011 at 9:52:51 PM, in mid:BANLkTi=nwtmcchq96olpkhdmovunsoq...@mail.gmail.com, Jerome Baum wrote: I don't think you get what kind of assumption we are talking about. There are two kinds: 1. I assume something is generally true, e.g.: I assume the world is around. 2. I assume something is true within this scope, so I don't have to restate the precondition with every statement I make, e.g.: assuming y z, and z x, we can follow that y x. It isn't really an argument to say you can't assume y z, so the point is invalid. I agree that in this specific instance we can assume y z. I do not agree that in general we can assume that an individual with expiry dates on their subkeys keeps their master key securely offline. ... which isn't what we were doing. Let me explain that again. Assuming something in general is a type 1 assumption. We were doing a type 2 assumption -- assuming something to simply a point. It would become tedious to keep writing if the individual in question keeps their master key securely offline before each and every sentence. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Saturday 07 May 2011, MFPA wrote: Hi On Friday 6 May 2011 at 10:18:29 PM, in mid:banlktin2w8ljxyghv3_5npfbsibhrp9...@mail.gmail.com, Jerome Baum wrote: If my key expired yesterday, no-one can forge a message with that key and claim it's from today. Never heard of a system clock that was wrong? I'll give a summary reply here for everyone stating it's still possible to make that signature. It's possible if the master key is compromised. I was assuming a sub-key with an expiration date. It is trivial to make that signature without compromising the master key. Suppose your master key is secure and offline but Mallory has control of your subkey that expired yesterday. Mallory can put their system clock back 24hrs to sign and send a message, and then truthfully claim the message was signed today. They can back up this claim with email headers and server logs demonstrating the clock discrepancy. This explains why digital signatures with legally binding date often (always?) require a timestamp by a certified third party. 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: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 9:56:14 PM, in mid:201105072256.15...@thufir.ingo-kloecker.de, Ingo Klöcker wrote: It depends on your definition of valid. In my book a signature can only be valid if the corresponding key is valid. Expired keys are not valid (anymore). I thought a key was incapable of making signatures with timestamps beyond its expiry time but could still be used to verify signatures that already existed. - -- Best regards MFPAmailto:expires2...@ymail.com A wise man once said ...I don't know. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxbcJnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pPPgD/0Gw 4SINz9JbMTzdQdTe3KL5KkaoyK15RziImH0U3mvfYFRsfjm4+F+u8LwaiKHMZQmk 1tbJPy284qBHMMapxVh6uQToVRHZhmjwlO70SAKKcF42cDWiNwW6cLzm+0a9xB1Y dqHxXECsPuJi7Ay52e5cvCMV7hL8xiqjKdrTKoLe =UTKJ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sunday 08 May 2011, Grant Olson wrote: === You seem to send messages from the future. ;-) On 5/6/11 3:48 PM, Ingo Klöcker wrote: On Thursday 05 May 2011, Hauke Laging wrote: What is the difference between these two options with respect to the point of confusion? Unless I'm missing something the difference is as follows: - With prolongation of the expiration time releases signed before the prolongation will keep having a valid signature. - If one creates a new subkey then releases signed with the old expired subkey(s) will have an invalid signature. One would have to re-sign the old releases with the new subkey. Nope. The old releases won't have an invalid sig as long as the sig was made before the expiration date. Expiring a key now doesn't invalidate a sig made yesterday. Gpg will print out a note saying the key is expired, but it's not as drastic as the error with a post-dated signature. Ahh. My bad. Thanks for the heads up. I wasn't aware of this difference between signatures made before and after the expiration date. 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: Best practice for periodic key change?
2011/5/7 Ingo Klöcker kloec...@kde.org This explains why digital signatures with legally binding date often (always?) require a timestamp by a certified third party. Not always (every statement of intent is binding, even w/out a notary), but e.g. over here (Germany) for a digital signature to reach a certain level of documentation, you will need a certification on the signature date -- even if the date isn't important, the certification is there to confirm the key was valid at the (actual) time of signing. BTW, the laws here enforce the keys to have an expiration date to reach that level. On digital signatures being legally binding, apparently a scanned bitmap of your signature is enough to be binding (as would be no signature), just that it isn't very strong documentation. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
2011/5/7 MFPA expires2...@ymail.com On Saturday 7 May 2011 at 9:56:14 PM, in mid:201105072256.15...@thufir.ingo-kloecker.de, Ingo Klöcker wrote: It depends on your definition of valid. In my book a signature can only be valid if the corresponding key is valid. Expired keys are not valid (anymore). I thought a key was incapable of making signatures with timestamps beyond its expiry time but could still be used to verify signatures that already existed. Definitely. I get his point about rejecting them entirely though, as it is (and that's what this dicussion is all about) difficult to verify the (actual) signature time. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 10:21:17 PM, in mid:banlktinacqcd+mz7fl1thlk55x2+u9g...@mail.gmail.com, Jerome Baum wrote: On digital signatures being legally binding, apparently a scanned bitmap of your signature is enough to be binding (as would be no signature), just that it isn't very strong documentation. What is to stop that scanned bitmap of a person's signature being applied to a document the individual has no knowledge about? - -- Best regards MFPAmailto:expires2...@ymail.com What's another word for synonym? -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxb6CnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p5E0D/2Km Hd1UD7MJX7lATCE7mliY16m99P2R/KRpmaET1MhXTFCaxghXLKGgWgiOxeeaK1Zu yPCQPsDOfPF85ujuwdp2fnAFH6IcYi+NT+1DxtmUEVTozdAVpjgfkXFR9290EwE9 VrdqymFv4itu+51rYIc8cLs+na33pHbcn/yNuPYo =frVX -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/07/2011 02:49 PM, MFPA wrote: What is to stop that scanned bitmap of a person's signature being applied to a document the individual has no knowledge about? Nothing. That's the nature of physical signatures. A physical signature binds tightly to the individual (handwriting being hard to forge), but loosely to the document. A digital signature binds loosely to the individual (certificate repudiation being pretty easy), but tightly to the document. This is one of the reasons why I generally dislike the way the word signature gets abused in these discussions. Comparisons to physical signatures inevitably arise, and the two of them seem quite a bit more dissimilar than alike. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 10:22:33 PM, in mid:banlktimrobi47ottgokkveeoh-ayroo...@mail.gmail.com, Jerome Baum wrote: Definitely. I get his point about rejecting them entirely though, as it is (and that's what this dicussion is all about) difficult to verify the (actual) signature time. Maybe we could use something like http://www.itconsult.co.uk/stamper.htm - -- Best regards MFPAmailto:expires2...@ymail.com Gypsy Dwarf Escapes Prison: Small Medium at large -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxcKTnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pzGQD/ipu LyjM5K28t279xg4t0OLLh81RbamxnPcJoja+V6/U2d9gzOQ/M63//qT6oz78GlHH R2lXxnv9EEQhV27Q7sGBWezXQLj5wnIAJH6C/qcqEhNpe9SxO8unkMyWUTgZwlpg tOCmo8S8kbmWOHKpQp4PoG3GUvPlWtgWtD3Ub819 =jhP/ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 5/7/2011 5:08 PM, Ingo Klöcker wrote: On Sunday 08 May 2011, Grant Olson wrote: === You seem to send messages from the future. ;-) That's funny. I wanted to make sure I wasn't lying before replying. A little later I was deploying code to some servers. After the update the interface said the servers were last updated two days ago. I was freaking out for about five minutes until I realized I changed my system clock. -- Grant signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sun, May 8, 2011 at 03:13, Jerome Baum jer...@jeromebaum.com wrote: On Sat, May 7, 2011 at 23:56, Robert J. Hansen r...@sixdemonbag.orgwrote: On 05/07/2011 02:49 PM, MFPA wrote: What is to stop that scanned bitmap of a person's signature being applied to a document the individual has no knowledge about? Nothing. That's the nature of physical signatures. I was talking about a digital signature though. MFPA: I agree about the signature being very weak. I am just repeating what German law says. This is from some brochure brought out by the BSI. It's also quite a right interpretation -- they aren't assigning much strength to it, it's what we have advanced and qualified electronic signatures for. The bitmap scan is still digital though, and it is a signature. So, it is an electronic signature. Makes sense, just don't accept it in court. You realized you might be referring to the binding part. As I like to repeat, every statement of intent is binding. Signatures are just a kind of documentation, and as I said, it's not very strong documentation. I offer you 10 dollars if you give me 10 euros, and this is valid for two days from now. -- that statement of intent is legally binding (or it would be, if I were being serious). You can hold me to that. The problem is, you won't have much evidence I really made that statement and you'd have a hard time dragging me to court for this anyway. That doesn't make the statement less binding. Exceptions are found e.g. for home purchases, which AFAIK over here need to be documented in writing/on paper. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sat, May 7, 2011 at 23:56, Robert J. Hansen r...@sixdemonbag.org wrote: On 05/07/2011 02:49 PM, MFPA wrote: What is to stop that scanned bitmap of a person's signature being applied to a document the individual has no knowledge about? Nothing. That's the nature of physical signatures. I was talking about a digital signature though. MFPA: I agree about the signature being very weak. I am just repeating what German law says. This is from some brochure brought out by the BSI. It's also quite a right interpretation -- they aren't assigning much strength to it, it's what we have advanced and qualified electronic signatures for. The bitmap scan is still digital though, and it is a signature. So, it is an electronic signature. Makes sense, just don't accept it in court. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On May 7, 2011, at 5:49 PM, MFPA wrote: On Saturday 7 May 2011 at 10:21:17 PM, in mid:banlktinacqcd+mz7fl1thlk55x2+u9g...@mail.gmail.com, Jerome Baum wrote: On digital signatures being legally binding, apparently a scanned bitmap of your signature is enough to be binding (as would be no signature), just that it isn't very strong documentation. What is to stop that scanned bitmap of a person's signature being applied to a document the individual has no knowledge about? Nothing more than would stop someone from cutting and pasting (in the old scissors-and-paste sense of the term) a signature from one document to another, then copying the whole thing to make it look right. It's just easier and looks better with a graphics program than with scissors and glue. Incidentally, speaking of bitmap signatures - a signature made via a rubber stamp of a signature can be binding under certain circumstances as well (at least in the US - I don't know about elsewhere). David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sun, May 8, 2011 at 03:50, David Shaw ds...@jabberwocky.com wrote: Incidentally, speaking of bitmap signatures - a signature made via a rubber stamp of a signature can be binding under certain circumstances as well (at least in the US - I don't know about elsewhere). Often enough you don't need an actual signature, at least in Germany. Businesses that use a computer to generate invoices in batches just don't add a signature, which doesn't make the document less valid. Funny enough they'll add a sentence saying this document was generated by an automated computer system and is thus legal without signature -- mostly because of the misconception that a signature is normally required -- but even if it weren't for the automated computer system, the document would still be valid. Remember documents are for *documentation*, but it's the (statement of) *intent* which is binding. At least in Germany. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/07/2011 09:50 PM, David Shaw wrote: Incidentally, speaking of bitmap signatures - a signature made via a rubber stamp of a signature can be binding under certain circumstances as well (at least in the US - I don't know about elsewhere). Within the U.S., the standard doesn't involve signatures /qua/ signatures. It involves making a mark on a document to express your will. A contract signed with a simple mark of X is still legally binding. There's some hoary old story that was, once upon a time, taught in law schools: but Dad went through law school fifty years ago, so maybe it's fallen out of fashion. It involved a lawsuit brought against a bank by two farmers (in Vermont, I think). The first farmer owed the second a quantity of money, so the farmer picked up a grease pen and wrote on a pumpkin, Pay this man $10 from my checking account. The second farmer took it to the bank. The bank refused to honor the check. The two Vermont farmers were too stubborn to budge: it was a valid legal document and no rich banker was going to tell them otherwise. The bank refused to budge: if a *pumpkin* can become a valid check-writing instrument, what will that do to their bookkeeping process? The trial court ruled in favor of the farmers. (Warning: secondhand information passed on from a source recalling a story he heard fifty years ago. I'm led to believe the legal principles involved are still accurate in today's legal climate, but time and memory may have made this story a bit apocryphal.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Am Samstag, 7. Mai 2011, 21:43:38 schrieb MFPA: At what point does it become safe to assume that an individual with expiry dates on their subkeys keeps their master key securely offline? There is probability but no safety in this assumption. But it this relevant? How and whom is an expiration date supposed to protect? And what is the alternative? The user of a non-expired public key does not have to cope with any disadvantage by checking the expiration date. The alternative would be to accept the key in any case. That would obviously not be a security advantage. One might ask: Do users who observe expiration dates refresh their keyrings less often on average (due to false trust in the expiration feature)? Does it make sense for an attacker to replace non-expiring subkeys with expiring ones in order to reduce the refresh frequency of the ones being attacked by forged signatures? ;-) But there is security for the owner of the key. He knows that his mainkey is stored safely offline so that nobody will ever meet forged subkeys of this key. Thus he safely protects himself and his communication partners from the use of expired keys. I theory. In practice the key owner does not know whether his communication partners observe the expiration date. But he gives them the chance to do so. The theoretical model is safe. Reality usually suffers from worse security problems than that. As you may remember I promote both an implicit and an explicit solution of this problem (not knowing enough about others' key handling) here from time to time: a) Write a key policy describing this, too. Make this document available online and put its URL in all your certifications (including your selfsig) and signatures (policy URL). Have everyone who certifies your key sign this document (because this cannot beforged by someone who gets access to your key). The problem: You have to read this document. GnuPG cannot do this for you. b) Define some standard notations which give this information. From time to time I give courses for OpenPGP beginners in an organization I am a member of. We create two keys for them, one for playing around and lerning to use GnuPG and a more secure one. When I certify these keys I add a notation offline@ourdomain=yes. So anyone using our certifications and understanding both offline keys and notations (so probably noone) can know how these keys are used – OK, nearly: How there were supposed to be used. There could be a different term for keys which have been created elsewhere but are claimed to be offline keys. offline-claimed@ourdomain=yes or something like that. If there was a standard for this GnuPG could be extended to allow for a configuration taking this into account. The extreme version: Trust certifications of others only if they are offline keys. And as I am dreaming: With a notation for identifying all subkeys (thus extending a certification from UIDs to subkeys) the first hurdle for getting GnuPG / OpenPGP compliant with German signature law (at least on the theoretical level) would be taken. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
On May 7, 2011, at 10:21 PM, Robert J. Hansen wrote: On 05/07/2011 09:50 PM, David Shaw wrote: Incidentally, speaking of bitmap signatures - a signature made via a rubber stamp of a signature can be binding under certain circumstances as well (at least in the US - I don't know about elsewhere). Within the U.S., the standard doesn't involve signatures /qua/ signatures. It involves making a mark on a document to express your will. A contract signed with a simple mark of X is still legally binding. Yes. I was referring to the UCC, where they define the term signature fairly expansively as a signed name, a trade name, or pretty much any other mark. The intent to authenticate is the point, not that fact that it's a written name, signed name, or other scribble. I knew a man (a lawyer, as it happened) who always signed documents with several loops in a row. When I asked him why he didn't use a real signature (i.e. why he didn't sign his name), he just grinned and said Who's to say this isn't my signature? My own signature is sufficiently unreadable that it could safely be described as a mark. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sun, May 8, 2011 at 00:07, MFPA expires2...@ymail.com wrote: Maybe we could use something like http://www.itconsult.co.uk/stamper.htm I checked the newsgroup (only through Google, last posting from '05) and don't see the signatures being posted anymore. Can anyone confirm this? -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sun, May 8, 2011 at 04:53, David Shaw ds...@jabberwocky.com wrote: I knew a man (a lawyer, as it happened) who always signed documents with several loops in a row. When I asked him why he didn't use a real signature (i.e. why he didn't sign his name), he just grinned and said Who's to say this isn't my signature? My own signature is sufficiently unreadable that it could safely be described as a mark. Speaking of which, there was thishttp://www.nytimes.com/2011/04/28/us/28cursive.htmlarticle recently on how people aren't learning cursive writing anymore and this makes (physical) signature verification more difficult. My signature is a semi-readable cursive Jerome Baum (read: Jer~~~ B~~~ ;) ) so I should be safe, but I'm wondering how secure it actually is? Anybody know a good article on physical signature security? I know the analyses are all about writing speed and pressure but it would be good to see this dumbed down for casual reading. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On May 7, 2011, at 10:57 PM, Jerome Baum wrote: On Sun, May 8, 2011 at 00:07, MFPA expires2...@ymail.com wrote: Maybe we could use something like http://www.itconsult.co.uk/stamper.htm I checked the newsgroup (only through Google, last posting from '05) and don't see the signatures being posted anymore. Can anyone confirm this? They're certainly still coming up on alt.security.pgp. Here is the one for last week: http://groups.google.com/group/alt.security.pgp/browse_thread/thread/8f29de04c2ddd19b# David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On May 7, 2011, at 11:04 PM, Jerome Baum wrote: On Sun, May 8, 2011 at 04:53, David Shaw ds...@jabberwocky.com wrote: I knew a man (a lawyer, as it happened) who always signed documents with several loops in a row. When I asked him why he didn't use a real signature (i.e. why he didn't sign his name), he just grinned and said Who's to say this isn't my signature? My own signature is sufficiently unreadable that it could safely be described as a mark. Speaking of which, there was this article recently on how people aren't learning cursive writing anymore and this makes (physical) signature verification more difficult. My signature is a semi-readable cursive Jerome Baum (read: Jer~~~ B~~~ ;) ) so I should be safe, but I'm wondering how secure it actually is? Anybody know a good article on physical signature security? I know the analyses are all about writing speed and pressure but it would be good to see this dumbed down for casual reading. I bookmarked this at one point: www.thomasgroganfde.com/pdf/Article_Protect_Identity.pdf He gives a few recommendations (cross your own lines frequently, consistency is important, think about using a different signature for legal matters vs correspondence, etc). How good the advice is I couldn't say, but I found it and some other documents on the site interesting reading. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: Best practice for periodic key change?
Hey Matthew, http://www.itconsult.co.uk/stamper/stampinf.htm refers to comp.security.pgp.announce but I can't find recent postings there (only some references to the newsgroup being closed). If that's true, you might want to update the page. -- Forwarded message -- From: David Shaw ds...@jabberwocky.com Date: Sun, May 8, 2011 at 05:15 Subject: Re: Best practice for periodic key change? To: Jerome Baum jer...@jeromebaum.com Cc: MFPA expires2...@ymail.com, Jerome Baum on GnuPG-Users gnupg-users@gnupg.org On May 7, 2011, at 10:57 PM, Jerome Baum wrote: On Sun, May 8, 2011 at 00:07, MFPA expires2...@ymail.com wrote: Maybe we could use something like http://www.itconsult.co.uk/stamper.htm I checked the newsgroup (only through Google, last posting from '05) and don't see the signatures being posted anymore. Can anyone confirm this? They're certainly still coming up on alt.security.pgp. Here is the one for last week: http://groups.google.com/group/alt.security.pgp/browse_thread/thread/8f29de04c2ddd19b# David -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Thu, May 5, 2011 at 4:10 PM, Doug Barton do...@dougbarton.us wrote: On 05/04/2011 23:52, Andreas Heinlein wrote: We have a OpenPGP key which we use for signing our software releases. That key should be changed yearly and carry an expiration date to enforce this change. What are you trying to accomplish by doing it this way? I've yet to see a good rationale for setting expiration dates on keys, but perhaps you can be the first. :) I would guess that Andreas is practicing Key Management (http://www.cacr.math.uwaterloo.ca/hac/about/chap13.pdf). I've also seen similar arise in compliance and auditing. Jeff ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Am 05.05.2011 22:10, schrieb Doug Barton: On 05/04/2011 23:52, Andreas Heinlein wrote: We have a OpenPGP key which we use for signing our software releases. That key should be changed yearly and carry an expiration date to enforce this change. What are you trying to accomplish by doing it this way? I've yet to see a good rationale for setting expiration dates on keys, but perhaps you can be the first. :) Well, there are several reasons. The first is that there is always the chance that the key is cracked brute-force. Remember that the x-zillion years which are often cited are only an average. One might always be lucky and find the right one within the first 0.0001% of keyspace, taking only a few days or weeks. Chance is very low, but then almost every week someone wins the lottery... ;-) More likely your key gets compromised some other way, e.g. it is stolen from your computer by a trojan, a malicious website or whatever. A good passphrase mitigates this risk somewhat, but most people choose passphrases which are weaker and easier to brute-force than the actual key. Here comes the third point; even if you notice your key was compromised, you need to revoke it *and* make sure the revocation reaches all users of your key. Like Werner said, many people never refresh their keys, so expiring is indeed a way to force them to do that. ( I admit that, in our case, even this will not help, since gpg will happily verify a signature made by an expired key. It will tell you that it's expired, but verify anyway. The 'hard' way would be to just refuse to do anything with an expired key or even delete it automatically, but that's another discussion). Much depends on the use case you're using GPG for, there's another discussion currently on this topic. Werner's approach still doesn't satisfy me, as it doesn't protect you from someone else using your (compromised) key as long as you don't notice it. Andreas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/05/2011 23:22, Andreas Heinlein wrote: Like Werner said, many people never refresh their keys, so expiring is indeed a way to force them to do that. ( I admit that, in our case, even this will not help, since gpg will happily verify a signature made by an expired key. It will tell you that it's expired, but verify anyway. The 'hard' way would be to just refuse to do anything with an expired key or even delete it automatically, but that's another discussion). Obviously you've thought through one side of the problem of key compromise (which I've snipped), but I'm not sure you've thought through the ramifications of what's going to happen after the bad guys get your key. You create a key with an expiration date. You sign stuff with it. Users download your stuff, the signature, and your key, and verify the signature on your stuff. All good. Now the bad guys get your key (oops!). They sign malicious versions of your code, and upload it. Users who still have your (now compromised) key will still be able to verify the signatures (as you pointed out). The tiny percentage of users who periodically refresh their keys, and care that the key has expired, _may_ notice something is wrong, probably not. Even if the user doesn't already have the key, most keyservers don't hesitate to serve up keys that are expired, or even revoked. There's also another element, the expiration date is irrelevant if the key is actually compromised. If Eve has your secret key she can simply update or remove the expiration date, and upload the new version of the public key to the public keyservers. So, I remain confused as to what purpose expiration dates on the keys will serve. One could make an argument for creating new keys (or subkeys) on an annual basis with a comment to the effect of This key is only valid for signatures created during calendar year 2011. However, asking users to parse that is likely to be more than they are able or willing to do. And even that can be trivially compromised if Eve changes the clock on her computer before generating the signature. In short, rotating keys, with or without an expiration date _may_ add single-digit percentage points of security to your intended use, but you'd be far better off with a good management policy for your secret key (you've been given some good suggestions already) to reduce as much as possible the potential for having it compromised. Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/06/2011 03:47 AM, Doug Barton wrote: There's also another element, the expiration date is irrelevant if the key is actually compromised. If Eve has your secret key she can simply update or remove the expiration date, and upload the new version of the public key to the public keyservers. So, I remain confused as to what purpose expiration dates on the keys will serve. This is a critical observation. expiration dates are safeguards against a key becoming inaccessible to the legitimate keyholder -- not against compromise. There are other safeguards against keys becoming inaccessible, including a safely-stored revocation certificate. Expiration dates have the advantage over revocation certificates that you do not need to keep track of anything or maintain safe and secure longterm storage. A safely-stored revocation certificate *also* protects against key compromise, though, so you really ought to have one anyway. Consider the expiration date as a safeguard against simultaneous loss (not compromise) of the key and loss of the revocation certificate. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Am Freitag, 6. Mai 2011, 09:47:57 schrieb Doug Barton: There's also another element, the expiration date is irrelevant if the key is actually compromised. If Eve has your secret key she can simply update or remove the expiration date, and upload the new version of the public key to the public keyservers. That's not correct for subkeys and offline mainkeys as the good guys do it. I admit that a subkey expiration date does not make much sense for low security mainkeys but it is quite useful for more secure environments. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
On Thursday 05 May 2011, Hauke Laging wrote: Am Donnerstag, 5. Mai 2011, 11:19:30 schrieb Werner Koch: A period key change is problematic because it confuses those who want to verify the signatures. BTW, the prolongation of the expiration time has showed (by means of a lot of complaining mails) that many folks don't refresh the key from time to time with the goal to retrieve revocation certificates. What is the difference between these two options with respect to the point of confusion? Unless I'm missing something the difference is as follows: - With prolongation of the expiration time releases signed before the prolongation will keep having a valid signature. - If one creates a new subkey then releases signed with the old expired subkey(s) will have an invalid signature. One would have to re-sign the old releases with the new subkey. 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: Best practice for periodic key change?
On 05/06/2011 08:34, Hauke Laging wrote: Am Freitag, 6. Mai 2011, 09:47:57 schrieb Doug Barton: There's also another element, the expiration date is irrelevant if the key is actually compromised. If Eve has your secret key she can simply update or remove the expiration date, and upload the new version of the public key to the public keyservers. That's not correct for subkeys and offline mainkeys as the good guys do it. I don't understand this response. What I'm saying is that if the key is compromised, expiration dates become irrelevant. Perhaps you could expand your response a bit? I admit that a subkey expiration date does not make much sense for low security mainkeys but it is quite useful for more secure environments. How so? I still haven't seen an explanation of what benefit the expiration date provides. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Fri, May 6, 2011 at 22:37, Doug Barton do...@dougbarton.us wrote: I don't understand this response. What I'm saying is that if the key is compromised, expiration dates become irrelevant. Up to a point. If my key expired yesterday, no-one can forge a message with that key and claim it's from today. Just being nit-picky... :) -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 5/6/11 4:48 PM, Jerome Baum wrote: On Fri, May 6, 2011 at 22:37, Doug Barton do...@dougbarton.us mailto:do...@dougbarton.us wrote: I don't understand this response. What I'm saying is that if the key is compromised, expiration dates become irrelevant. Up to a point. If my key expired yesterday, no-one can forge a message with that key and claim it's from today. Just being nit-picky... :) Doug is saying that if the key's been compromised, and not lost, Eve can create a new expiration date and push that to the keyservers. -- Grant I am gravely disappointed. Again you have made me unleash my dogs of war. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/06/2011 13:48, Jerome Baum wrote: On Fri, May 6, 2011 at 22:37, Doug Barton do...@dougbarton.us mailto:do...@dougbarton.us wrote: I don't understand this response. What I'm saying is that if the key is compromised, expiration dates become irrelevant. Up to a point. If my key expired yesterday, no-one can forge a message with that key and claim it's from today. That's absolutely not true. New signatures can be created with expired keys, and as Werner pointed out new signatures can be created with keys that have had their expiration dates updated, and although a percentage of users may inquire about it, it's usually the know just enough to be dangerous contingent (I.e., those smart enough to know that the key is expired on their key ring, but not smart enough to refresh it). There may be a tiny percentage of users who are smart enough to do both, who would then realize that the signature is invalid. However given that the scenario you described (forgery, vs. key compromise) is so overwhelmingly unlikely to happen (at least in any kind of meaningful way) I'm not sure it's worth considering. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 6 May 2011 at 8:48:03 PM, in mid:201105062148.04...@thufir.ingo-kloecker.de, Ingo Klöcker wrote: Unless I'm missing something the difference is as follows: - With prolongation of the expiration time releases signed before the prolongation will keep having a valid signature. - If one creates a new subkey then releases signed with the old expired subkey(s) will have an invalid signature. One would have to re-sign the old releases with the new subkey. Surely the signature on the old release would still be valid; it would just be from a now-expired subkey instead of from the new and currently-valid subkey. Or have I overlooked something? - -- Best regards MFPAmailto:expires2...@ymail.com Of course it's a good idea - it's mine! -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxGIFnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pSkUD/3SU IPu98qzm8wAsXVjnvwkn8rZD8x3Q5V9Xre3+uV5k2G6VEwDV75NXkG65pE4Ol/+c 4Ex7+qny7QhK+8xL2xyTsZGSVGZyYgsjkKlRTw2ocD64leu15Q9+RQxdR2ummqA5 9Z8XT3CWnkjGLHIKNNgey2xX8ZsHHIOKCXqdpfXM =A0bx -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 6 May 2011 at 9:48:26 PM, in mid:banlktim3-dgy2ngvetevfjsxng8m5c2...@mail.gmail.com, Jerome Baum wrote: If my key expired yesterday, no-one can forge a message with that key and claim it's from today. Never heard of a system clock that was wrong? - -- Best regards MFPAmailto:expires2...@ymail.com Was time invented by an Irishman named O'Clock? -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxGMynhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pRC4EAJtX H2825By7Iq5kehVu6s5XlpN7GFOMeIbsV/vjXRF3zg1jdIJtA/pvh5U+mnzDJn7U X86OJUR/KArkrqBZi15fI95/CB/wfKEEdFVOT+o8y6XhI5pwRyugg+Im2L69/Yp7 E7pJ5TKQMucMsWCuTneUDJr+Lm+aLoaWaQ/ZZHxB =JS9G -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: Re: Best practice for periodic key change?
Meant to sent on-list... Original Message Subject: Re: Best practice for periodic key change? Date: Sun, 08 May 2011 16:39:34 -0400 From: Grant Olson k...@grant-olson.net To: Ingo Klöcker kloec...@kde.org On 5/6/11 3:48 PM, Ingo Klöcker wrote: On Thursday 05 May 2011, Hauke Laging wrote: What is the difference between these two options with respect to the point of confusion? Unless I'm missing something the difference is as follows: - With prolongation of the expiration time releases signed before the prolongation will keep having a valid signature. - If one creates a new subkey then releases signed with the old expired subkey(s) will have an invalid signature. One would have to re-sign the old releases with the new subkey. Nope. The old releases won't have an invalid sig as long as the sig was made before the expiration date. Expiring a key now doesn't invalidate a sig made yesterday. Gpg will print out a note saying the key is expired, but it's not as drastic as the error with a post-dated signature. -- Grant I am gravely disappointed. Again you have made me unleash my dogs of war. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Fri, May 6, 2011 at 23:07, MFPA expires2...@ymail.com wrote: On Friday 6 May 2011 at 9:48:26 PM, in mid:banlktim3-dgy2ngvetevfjsxng8m5c2...@mail.gmail.com, Jerome Baum wrote: If my key expired yesterday, no-one can forge a message with that key and claim it's from today. Never heard of a system clock that was wrong? I'll give a summary reply here for everyone stating it's still possible to make that signature. It's possible if the master key is compromised. I was assuming a sub-key with an expiration date. I haven't checked, but I pray that sub-key expiration dates are signed with the master key. That sub-key, by the way, was also the original context where I mentioned the forgery. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 6 May 2011 at 10:18:29 PM, in mid:banlktin2w8ljxyghv3_5npfbsibhrp9...@mail.gmail.com, Jerome Baum wrote: If my key expired yesterday, no-one can forge a message with that key and claim it's from today. Never heard of a system clock that was wrong? I'll give a summary reply here for everyone stating it's still possible to make that signature. It's possible if the master key is compromised. I was assuming a sub-key with an expiration date. It is trivial to make that signature without compromising the master key. Suppose your master key is secure and offline but Mallory has control of your subkey that expired yesterday. Mallory can put their system clock back 24hrs to sign and send a message, and then truthfully claim the message was signed today. They can back up this claim with email headers and server logs demonstrating the clock discrepancy. Maybe implausible but definitely trivial. - -- Best regards MFPAmailto:expires2...@ymail.com Ultimate consistency lies in being consistently inconsistent -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxHjhnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pa2QEALud O9yvta6V10S80QQnSCHm70qYvUvgD5tIBi8WwPSDmtDN/jdOQuFJvxc5DfcrJY4d xNk7+bDdAOoTuB42Sc+VHKx54GlKzqSKj4prg4LLOcZYzhoQCmOfMoGOeWCrKZ/0 k3HoSq9u3AyoYjj++VMf3CCXEjrfV+E8yJmVQVtZ =WL/J -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sat, May 7, 2011 at 00:40, MFPA expires2...@ymail.com wrote: On Friday 6 May 2011 at 10:18:29 PM, in mid:banlktin2w8ljxyghv3_5npfbsibhrp9...@mail.gmail.com, Jerome Baum wrote: If my key expired yesterday, no-one can forge a message with that key and claim it's from today. Suppose your master key is secure and offline but Mallory has control of your subkey that expired yesterday. Mallory can put their system clock back 24hrs to sign and send a message, and then truthfully claim the message was signed today. They can back up this claim with email headers and server logs demonstrating the clock discrepancy. Maybe implausible but definitely trivial. Okay, let me rephrase that. claim it's from today should have been have the signature date as today. That's how I would interpret such a claim. Email headers don't really make a difference -- they would have signed it yesterday and sent it today, but the message is still from yesterday. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Sat, May 7, 2011 at 01:01, Jerome Baum jer...@jeromebaum.com wrote: Okay, let me rephrase that. claim it's from today should have been have the signature date as today. That's how I would interpret such a claim. Email headers don't really make a difference -- they would have signed it yesterday and sent it today, but the message is still from yesterday. Actually let me put this in context so you see what I mean. Say my sub-key expired yesterday. Today, you come up to me and ask me to sign something (say, a statement that I agree to specific contractual terms). Whoever is in possession of my sub-key cannot sign that document as at the time that the statement was made available to me for signing, the sub-key was already invalid. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 12:11:06 AM, in mid:BANLkTimNq9nxpf23=pe2n0rr1stnh3a...@mail.gmail.com, Jerome Baum wrote: Actually let me put this in context so you see what I mean. I already see what you mean; I just happen to disagree. (-; Say my sub-key expired yesterday. Today, you come up to me and ask me to sign something (say, a statement that I agree to specific contractual terms). Whoever is in possession of my sub-key cannot sign that document as at the time that the statement was made available to me for signing, the sub-key was already invalid. The timestamp of the signature proves nothing. It is merely the time on the system clock when the signature was made. The system clock may be correct or incorrect; in your scenario above, it looks like you set it deliberately a day behind in an attempt to generate plausible deniability for your signature. - -- Best regards MFPAmailto:expires2...@ymail.com Ultimate consistency lies in being consistently inconsistent -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNxIe8nhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pkBMEAKrg GwnIdzVfOnq/hx5Jn/fJ4qoky8jpQQke58wKSuioX68DgZfAbpf9o01PHowfzMHT bS7JAbSJEV1R874A7lGVRaVnWekD7J9aCgVFp/EiN+ehUGK91357HO6d6fH9eNKS RQvRiFNr/1x1tPGHEXHox26Vs2PJaEjs3wRBJMvJ =sv0T -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 7 May 2011 at 12:01:30 AM, in mid:banlktik+i0ml2fozkzbzpt+ykoojycs...@mail.gmail.com, Jerome Baum wrote: Email headers don't really make a difference -- they would have signed it yesterday and sent it today, but the message is still from yesterday. OK, when was this message signed? When was it sent? When did the server receive it? - -- Best regards MFPAmailto:expires2...@ymail.com Zorba the Greek - before he zorbas you -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNwzflnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p3pAEAJcU tllXwlRN7I9B3C2hNpGi40/Q52biJxpWLK2xXg4oaYGTzt6yF/eNHsUJX1uKioYi V14k2wQfZVCZK47k9507vxYUEZQd8Pq6HtMEHWC5luwdpoNCU2Rceu28hFuvo+s4 JYcM6CQBvCAF8BVMhU+GQmkr8wIylCRXRh6Rqt0O =ciXV -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
Am Freitag, 6. Mai 2011, 21:48:03 schrieb Ingo Klöcker: What is the difference between these two options with respect to the point of confusion? Unless I'm missing something the difference is as follows: - With prolongation of the expiration time releases signed before the prolongation will keep having a valid signature. I am a bit disappointed that it seems not to be possible to change this by an option. It seems to me that you have to parse text output which is not intended for parsing. There is no --with-colons for --verify, or do I just not notice such a feature? Several people have mentioned that a signature does not become invalid by expiration of the key. That is formally correct an describes the GnuPG behaviour. But with regard to content in such a case there has to be an additional proof that the signature has been made before the key expired. This is a formal rule in e.g. the German signature law. If you want to use legally accepted signatures for proving documents then you have to sign both the document and the old signature by a new key (i.e. one with a later expiration date) before the old key expires. I would prefer GnuPG to work this way: Make a signature by an expired key fail by (configured) default and add an option like --ignore-key-expiration which can be used for a second gpg call (after an external verification that the signature has been made in time). And I would like to have a verification option for output intended for parsing. We can have a long discussion about the interpretation of signatures by expired keys (apparently made before the expiration). But as there is IMHO no way to really make sure that you have the current version of a key (and thus all revocations) I regard an expiration date as a last line of defense. Thus I think that it does not make sense to (effectively) ignore such an expiration by default. Nobody is forced to set expiration dates. Newer subkeys are used automatically without the old ones being revoked or expired. - If one creates a new subkey then releases signed with the old expired subkey(s) will have an invalid signature. That didn't make any sense to me so I checked that. This seems to be wrong. I have not noticed any change in the verification output (or exit code) between a valid subkey existing beside the expired one or not. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
Am Freitag, 6. Mai 2011, 22:37:12 schrieb Doug Barton: That's not correct for subkeys and offline mainkeys as the good guys do it. I don't understand this response. What I'm saying is that if the key is compromised, expiration dates become irrelevant. Perhaps you could expand your response a bit? You have to tell apart two cases: a) The mainkey is compromised. b) The subkey is compromised. If someone keeps his mainkey offline and well passphrase-protected then it is quite unlikely that the mainkey becomes compromised. If only the subkey gets compromised then it is not possible to change the subkey's expiration date. Thus your argument works for (a) only which can easily be prevented from happening. I admit that a subkey expiration date does not make much sense for low security mainkeys but it is quite useful for more secure environments. How so? I still haven't seen an explanation of what benefit the expiration date provides. That is a last line of defense as it is quite hard to be sure to have the current version of a key under normal circumstances. And it works for people who are lazy with key refreshing. Of course, you cannot be sure when a subkey will become compromised. Probably you won't even notice. But a short life time limits the danger resulting from a compromised key. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
On 5/6/2011 10:05 PM, Hauke Laging wrote: Several people have mentioned that a signature does not become invalid by expiration of the key. That is formally correct an describes the GnuPG behaviour. But with regard to content in such a case there has to be an additional proof that the signature has been made before the key expired. This is a formal rule in e.g. the German signature law. If you want to use legally accepted signatures for proving documents then you have to sign both the document and the old signature by a new key (i.e. one with a later expiration date) before the old key expires. I know nothing about German laws, but that just doesn't sound right to me. 1) I digitally sign a document saying I owe you money. The signing key has an expiration date. 2) Key expires. I do nothing. 3) The original document is invalidated. I no longer owe you money? signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Best practice for periodic key change?
Hello, I hope you can give me some advice on the following problem: We have a OpenPGP key which we use for signing our software releases. That key should be changed yearly and carry an expiration date to enforce this change. However, for the signatures to be useful, the key has to be signed by quite a lot of well-known people and institutions, which means a considerable effort. If we just regenerate the whole key every year, we would have to get all these signatures again. I have a feeling that generating new subkeys might be a solution, but I have never worked with subkeys before, so I thought you could give me some advice what would be the best thing to do. Thanks, Andreas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On Thu, 5 May 2011 08:52, aheinl...@gmx.com said: We have a OpenPGP key which we use for signing our software releases. That key should be changed yearly and carry an expiration date to enforce this change. However, for the signatures to be useful, the key has to be signed by quite a lot of well-known people and institutions, which means a considerable effort. What I do is to prolong the expiration date shortly before the key expires. Further I use a smartcard to protect the signing key. A period key change is problematic because it confuses those who want to verify the signatures. BTW, the prolongation of the expiration time has showed (by means of a lot of complaining mails) that many folks don't refresh the key from time to time with the goal to retrieve revocation certificates. Salam-Shalom, 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
Re: Best practice for periodic key change?
Am Donnerstag, 5. Mai 2011, 11:19:30 schrieb Werner Koch: A period key change is problematic because it confuses those who want to verify the signatures. BTW, the prolongation of the expiration time has showed (by means of a lot of complaining mails) that many folks don't refresh the key from time to time with the goal to retrieve revocation certificates. What is the difference between these two options with respect to the point of confusion? In my understanding people either refresh their keys often enough or not. If they do so then they have either old subkeys with renewed expiration date or completely new subkeys. In both cases the should not notice the update; the verification result is the same. Are there people who check the subkey IDs of old and new signatures, get confused by a change despite of gpg saying it's all right (which IMHO demands they have not understood the concept of subkeys)? BTW: Would it be a good idea for gpg to suggest the user to check for an updated version of the key (or do it automatically before if configured to do so) if it find an expired subkey? This would probably not work with the GUIs though (but might make the GUI developers offer a similar feature). Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 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: Best practice for periodic key change?
On Thu, 5 May 2011 17:07, mailinglis...@hauke-laging.de said: Are there people who check the subkey IDs of old and new signatures, get confused by a change despite of gpg saying it's all right (which IMHO demands they have not understood the concept of subkeys)? No they are confused that I signed a tarball with an expired key. Well expired according to their old copy of the key. BTW: Would it be a good idea for gpg to suggest the user to check for an updated version of the key (or do it automatically before if configured to do so) if it find an expired subkey? This would probably not work with the GUIs Not for GPG but for the MUA they use. It could be part of the error message the MUA displays if no key or only an expired key was found. For example a button refresh key and retry. It's all in GPGME. Salam-Shalom, 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
Re: Best practice for periodic key change?
Hauke Laging wrote: BTW: Would it be a good idea for gpg to suggest the user to check for an updated version of the key (or do it automatically before if configured to do so) if it find an expired subkey? This would probably not work with the GUIs though (but might make the GUI developers offer a similar feature). Hi, Hauke. What you are suggesting sounds quite doable. It sounds like a slight variation of the auto-key-retrieve keyserver-option. An expired (sub)key could trigger the same code to refresh the key, maybe calling the option auto-refresh-expired or something similar. -John -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 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: Best practice for periodic key change?
On 5/5/11 2:52 AM, Andreas Heinlein wrote: Hello, I hope you can give me some advice on the following problem: We have a OpenPGP key which we use for signing our software releases. That key should be changed yearly and carry an expiration date to enforce this change. However, for the signatures to be useful, the key has to be signed by quite a lot of well-known people and institutions, which means a considerable effort. If we just regenerate the whole key every year, we would have to get all these signatures again. I have a feeling that generating new subkeys might be a solution, but I have never worked with subkeys before, so I thought you could give me some advice what would be the best thing to do. Thanks, Andreas Some organizations create a master signing key, which is (supposedly) kept secure and usually off-line. That's used to sign the release keys. Then users sign the master key and/or see if the master key trusts the key used to sign the release. Like all the solutions proposed here, I have no idea how usable this strategy is for people who try to verify software packages, but only have a limited understanding of OpenPGP's trust model. -- Grant I am gravely disappointed. Again you have made me unleash my dogs of war. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice for periodic key change?
On 05/04/2011 23:52, Andreas Heinlein wrote: We have a OpenPGP key which we use for signing our software releases. That key should be changed yearly and carry an expiration date to enforce this change. What are you trying to accomplish by doing it this way? I've yet to see a good rationale for setting expiration dates on keys, but perhaps you can be the first. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
