Does PKCS #7 (CMS) add assurance to an email if a CRL/OCSP response is included, then revoked?

Question

Suppose I issue a signing certificate in January, and have a daily CRL issued (expires in 1 day) to verify the validity of that signature.

Then sometime in July I need to revoke that certificate.

My goal is to not invalidate all prior emails signed with that key, but, rather give recipients some assurance that the key was valid and correct when they received the message. CMS/PKCS7 might do what I'm needing IF:

• The sending client includes the revocation response in the message
• The signing PKI infrastructure is correct and not flawed
• The validator will see the SMIME signature, validate it, and also validate the signature as well.
• Does this whole concept fall apart if when the certificate is expired/superseded and not lost due to theft/loss of integrity of the private key?

Given the inconsistent support for SMIME (e.g. gmail and all things Google) is there any software or technology that would validate in the way that solves my needs?

Is what I'm looking for viable, or am I using the wrong technology for the wrong purpose?

Answer 1

What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem.

The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the signature was correct, and act on that belief -- even if the signature is no longer verifiable at date T', e.g. because the signer's certificate was revoked in the mean time.

In the case of revocation, each revocation information (be it in a CRL or an OCSP response) comes with a revocation date. The field is called revocationDate in a CRL and is defined in the following way:

The date on which the revocation occurred is specified.

So when a CRL says that a certificate was revoked on June 17th, at 14:10 +00:00, it also implicitly says that on June 15th, the certificate was not revoked. Therefore, if the recipient can somehow make sure that he received the email (and its signature) at a date prior to the revocation date, and that the stored email was not altered in any way, then the signature is still, conceptually, verifiable.

A serious hole in the theory above is that existing CA do not necessarily write revocation dates with all the needed accuracy. For instance, if you revoke twice the same certificate with Microsoft's PKI (Active Directory Certificate Services), then the revocation date will be the date of the second revocation, not the first. But if you manage certificates on smart cards with Microsoft's FIM CM product (Forefront Identity Management -- Certificate Management), then you will make such duplicate revocations.

---

In general, proofs of existence of some piece of data at a previous date rely on time stamps. For long-term archival of signed documents, still verifiable years after (not only after the signer's certificate has expired, but also after some of the intermediate CA certificate have also expired), you need to apply time stamps on a regular basis, like a layer of fresh paint. Some standards exist for that, but they are little more complex than simple CMS (CAdES builds on CMS, but with some rather hairy extra attributes). See this answer for some more discussion and pointers.