0.9.0 expiration date: does not work

[David Hayes]

On Thu, Jan 07, 1999 at 11:56:30PM -0800, Brian Warner wrote:
> in the future. The safe assumption is that the moment the key expires, the
> secret bits are flung out all over the net. Anything done with the secret
> key after that point is not guaranteed to represent the real owner.

 [snip]

> So I guess I'd print out two kinds of warnings when verifying signatures, one
> if the key had already expired by the time the signature was created, and
> another if the key has expired before "now" (when the verification is done).

The first kind should be an ERROR, not a WARNING. That is, if the
signature claims to be made after the expiration of the key, then the
signature is INVALID. This should be distinguishable from invalid
because the signature doesn't have the correct checksum, in case the
user or another program wants to make the distinction. But it should be
an ERROR. After all, who can trust a signature made by a secret key that
was scattered across the net? :-)

> The first tells you that the owner of the key was lazy and used a key that had
> already expired (or they're having severe temporal disturbances). 

This shouldn't be allowed to happen. "Original" use of a key (generating
a signature or encrypting to it) after the key's expiration date should
be a prohibited action. 

> Clearly any private key operations (signing, decryption) should emit a
> warning, if just to remind the user that they should have generated a new key
> by now.
> 
> I'd warn on encryption too, suggesting that the user try to find a more
> up-to-date key for that recipient.

People tend to ignore warnings. Programs used in a pipeline tend to
ignore them, too, looking for the more easily used exit status code.
These actions should be an ERROR. GPG should refuse to do wrong things.

If you really insist on the capability to do those things, I would be OK
with a command-line option to make those particular errors into warnings. 
-- 
David Hayes
david at hayes-family.org