Is long-term validity definitively corrupted upon TSA certificate revocation?

Question

Suppose a document that was signed with a long-term signature (e.g. CAdES-A): D S T1 (D - document, S - signature, T1 - time-stamp created using a time-stamping certificate C1). If C1 appears in the TSA's CRL, is there a way or a time period (an opposite of "grace period" from RFC 5126) to still recover the long-term validity of the signed document (e.g. by quickly time-stamping it with a new valid time-stamp)? Or is the validity of all documents time-stamped with this revoked certificate definitively lost in this case (unless the document was re-stamped earlier)?

(Of course, the document could have been double time-stamped by two distinct TSAa, but this is rarely done.)

Answer 1

When a certificate is revoked, the CRL contains the revocation date which tells at which date the certificate became "invalid". Indirectly, it specifies that the certificate was fine up to that date. For instance, if a private key is compromised after a burglary, the security camera recordings will be used to determine at which hour the key was stolen, and that will be the revocation date specified in the CRL.

If a TSA certificate is thus revoked, the archive validity can still be verified as long as a time stamp from another TSA covers the time stamp from the revoked certificate and specifies a date which is anterior to the revocation date. E.g., consider a chain which works thus:

• Time stamp S₁ claims that the signature (and signer's certificate and so on) existed at date T₁.
• Time stamp S₂ claims that the signature (and signer's certificate and so on) and the time stamp S₁ and the TSA certificate for S₁ and associated CRL and so on, all existed at date T₂.
• And so on.

If the TSA private key used to sign S₁ is compromised, or the TSA hit bankruptcy, or any similar situation, happens at date T', then the archive is still safe as long as T' > T₂: thanks to the time stamp S₂, one can validate S₁ as if the current date was T₂, and at that date the TSA was fine and the time stamp already existed.

For extra resilience, you want to use two distinct TSA with interleaved overlapping time stamps:

• Time stamps S₁, S₃, S₅... are from TSA A.
• Time stamps S₂, S₄, S₆... are from TSA B.
• You always apply time stamps in pairs. When the top-most time stamp is S_n and either of S_n-1 or S_n approaches expiration, you obtain two time stamps, from A and B, and thus increase the chain to length n+2.

With such a scheme, a discovered compromise of either A or B can still be recovered from, because in the chain of time stamps, you can "skip over" the rotten time stamp.

(Cryptographic details are relatively intricate; one important point is that a time stamp, as per RFC 3161, is a CMS SignedData with an explicit signed attribute which contains the hash value of the data that is time stamped; it follows that time-stamping an encoded time stamp is also an indirect time stamp for the original data. If that was not true, then you could run into cryptographic trouble about exclusive ownership, namely that a signature value is not necessarily as good as a hash. When you understand what I mean here, you will know enough to implement CAdES-A archive validation.)

---

The "grace period" is another mechanism for improved resilience. Its premise is that compromises are discovered after the fact, but usually not long after the fact. Applying a grace period of one week (for instance) means that you allow yourself to wait for one week, in case a past compromise is discovered. If after one week things still seem fine, then you begin to assume that though a compromise may have happened in the last five minutes (and you would not know of it yet), the situation was most probably clean one week ago. With time stamps obtained at the right moment, this can give a lot of extra resilience, at the expense of added complexity.