0.9.0 expiration date: does not work

[Brian Warner]

walberg at cig.mot.com (Tim Walberg) writes:
> 
> Yes, but with that in mind, the whole idea of expiring keys and
> trying to enforce or warn about their expiry is kinda moot anyway,
> because if I'm gonna change my systems clock, I might as well change
> it back to before the key even expired. I don't think that changing
> the system time is really an eventuality we need to worry about -
> possible (albeit infeasible) solutions would be to query a "known
> true" clock on the net somewhere to determine the current time
> (rather than calling time() et. al.), but even that can be rigged.

I'd think about it from the senders end: the purpose of having an expiration
date is to let the owner of a key stop worrying about compromise at some point
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.

But if a key can expire, then it cannot be used for an archival (never
expiring) signature. If you read the message after the key has expired (which
means it might have been signed after the key expired, since you don't really
know when the signature was made), then the key should not be trusted without
a trusted timestamp. You reading the message (or the message being securely
timestamped) puts an upper bound on the time of the signature, and it's the
signing that has to happen before the key expires.

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 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). The second
tells you that you waited too long to verify the message and now you can't
really be sure that the signature is valid.

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.

 -Brian