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 S1 claims that the signature (and signer's certificate and so on) existed at date T1.
- Time stamp S2 claims that the signature (and signer's certificate and so on) and the time stamp S1 and the TSA certificate for S1 and associated CRL and so on, all existed at date T2.
- And so on.
If the TSA private key used to sign S1 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' > T2: thanks to the time stamp S2, one can validate S1 as if the current date was T2, 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 S1, S3, S5... are from TSA A.
- Time stamps S2, S4, S6... are from TSA B.
- You always apply time stamps in pairs. When the top-most time stamp is Sn and either of Sn-1 or Sn 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.