0.9.0 expiration date: does not work

[David Pick]

> Werner Koch <wk at isil.d.shuttle.de>:
> > Bodo Moeller <Bodo_Moeller at public.uni-hamburg.de>:
> 
> >> Warnings are absolutely O.K., but it *should* be possible to use
> >> expired expired (signing or decryption) secret keys.  You might want,
> 
> > It is possible:
> > gpg --edit-key your-key
> >> expire
> > and set a new expiration date.
> 
> That's a possibility, but it's somewhat awkward.  Also, for decryption
> keys that I keep just in order to be able to decrypt old stuff, I
> would not really want to change the expiration date: The key _is_
> expired, I have no intention to change that -- I simply want to use
> it anyway.
> I'd still vote for a new option that makes gpg ignore validity
> periods.

Hmm. Looking at RFC 2440 it appears that the key validity data appears
in the public key packet (or signature subpacket for V4). The secret
key data is the public key and its appendant data *plus* the secret
keys multi-precision integers and a checksum. With V4 and the validity
period data moving into signature sub-packets (possibly different in
different signatures to affect the validity of that signature) the
one that matters is the self-signature (I think). But this is
signing the public key data. I think it's arguable (and I would argue
myself) that uses like the one described should not be excluded by
expiry dates. A *warning* that the key is expired is a good idea, but
I don't think myself that you should even have to quote an optional
parameter to allow the expired secret key to be used *for decryption*.
Of course, it should not be possible to use it for generating new
signatures, &c. or to use the public data for excryption. However,
it *should* be possible to use the public data for signature
checking - for example to recheck the signature on an old EMail
message some time after it was received.

If people feel there should be a new option, perhaps what should be
added is an option to tell gpg to run in a mode where the operations
that I mentioned that should be allowed should be allowed *if they
would be allowed on a specific date given in the parameter*. Then
(for example) an EMail package could pass the date of the message
to gpg to instruct it to check validity as of the date of the
message rather than the clock time. Such an option should *not*
allow clock time to be overridden for operations like encryption
or signature generation.

What do other people think of this suggestion? Does it meet the
perceived needs?

-- 
	David Pick