Verifying cryptographically signed files when the key has been revoked
Is there way to tell the differences between a revocation because of cycling and a revocation because of compromise?
Certificates.
Certificates usually include validility times, during which the associated public key is valid for use. Most certificates are issued for 1 up to 3 years and afterwards you need to cycle the certificate (and also maybe the associated key). With most better TOFU and pinning schemes you will still see and check the certificate and not solely trust on the pinned key, to ensure that the key is actually still valid and not expired nor revoked (which is handled via OCSP and CRLs).
But if the verification step only happens some time later, and in the mean time I revoke my key, how should this be handled?
This is actually a tricky problem, that requires some (2) changes to the way documents and data is signed and verified.
First, we need to change the OCSP responders. Right now, you usually only get "good", "unknown", "revoked" or "suspended" from the CA as an answer. This is clearly not enough, as you need to know when the certificate was revoked or suspended. Given this information you can actually check if the signature was issued before the key was compromised. Of course this still leaves the issue that anybody could just use a pre-revokation date for signing data.
To fix this issue, you need some more reliable way of time-stamping data than by letting the time stamp be created by the signer. You need to outsoure the timestamp, by either letting a trusted service sign a combination of the hash and the current time, by cleverly chaining the hashes like is done with Certificate Transparency or by insert an entry into the block chain.
As soon as you have a (valid-looking) signature with a trusted time stamp before the revokation date, you can rest assured that the signature is valid, but note that your signature should be included by the hash sent to the time stamping service to ensure nobody ripped it off and replaced it.
The alternative possible solution is to get rid off this whole revokation system and just (exclusively) use short-lived certificates where you can be sure that if it was revoked, that all the data in this short time frame could have been signed maliciously.