On 9/15/2014 at 3:57 PM, "Robert J. Hansen" <r...@sixdemonbag.org> wrote:
> if you really need the >ability to >encrypt to expired certificates, go right ahead and do it. >However, >there is something to be said for making people go through an >additional >couple of hoops before shooting themselves in the foot. ===== GnuPG tries to be very accommodating to almost all types of users, and has succeeded admirably in this case. I always wondered why anyone would ever really 'need' an expiration date, and how they would know in advance that they would need it to expire in the exact time they listed when the key was generated. A simple way to work around it, is to designate another one of the person's most trusted keys, as the 'revoker' key, or to generate a revocation certificate right after the key was made, and that way, if there is any future reason to not want people to encrypt to that key, to just revoke it then. But, if for whatever reason, one didn't do so, and lost the key or forgot the passphrase, and wanted the key to eventually 'pass on', then one could insure for its painless expiration, by making a timely expiration date ... Now, suppose someone got into the habit of routinely making an 'expiration' date, but still has the the secret key and passphrase, and didn't yet generate a newer encryption key, then it's nice for him to know that GnuPG allows for the possibility for people to still encrypt to that key, until he makes other arrangements, and that GnuPG is prudently set up so that it 'shouldn't be 'too easy' to do, so that one will think twice it one 'really' needs to do it. vedaal _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
