My question is about how to properly store RFC3161 tokens, so that their validity can be verified for a long time (aka "long term validation")
Let's say I use an RFC3161 (https://www.ietf.org/rfc/rfc3161.txt) to timestamp data (not signatures in this case, just the hash of some data that I want to prove existed at this point of time).
Let's say the certificate signing these tokens expires in about one year, but I want to be able to still prove in 10 years that my data existed at the current point in time.
Aside of keeping an eye on whether the involved algorithms are still considered secure over the period of these 10 years, what do I need to store NOW together with the TSA token so that in the future these timestamps can still be considere valid?
according to the rfc3161 specification, validation of timestamped signatures must work like this:
1) The time-stamp token itself MUST be verified and it MUST be
verified that it applies to the signature of the signer.
2) The date/time indicated by the TSA in the TimeStampToken
MUST be retrieved.
3) The certificate used by the signer MUST be identified and
retrieved.
4) The date/time indicated by the TSA MUST be within the
validity period of the signer's certificate.
5) The revocation information about that certificate, at the
date/time of the Time-Stamping operation, MUST be retrieved.
6) Should the certificate be revoked, then the date/time of
revocation shall be later than the date/time indicated by
the TSA.
Since in my case it is not about verifying the validity of a signature, I assume (please correct me if I'm wrong) this simplifies to:
1) The time-stamp token itself MUST be verified and it MUST be
verified that it applies to the timestamped data.
2) The date/time indicated by the TSA in the TimeStampToken
MUST be retrieved.
So, to verify in 10 years whether the timestamps are valid I assume what needs to be done to verify the validity of the token itself is:
1) retrieve all the certificates of the trust-chain up to the trust anchor of the certificate that signed the token
2) for each certificate, check the revocation status AT THE TIME OF TIMESTAMPING (certificates must not have been revoked and must have been valid)
3) for each certificate, check if the revocation status AT THE CURRENT TIME (in the future) and for those certificates that have been revoked by then, check that the reasonCode extension is present and is one of unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5) (this is specified in section 4 of the specification, "Security Considerations")
If these things check out, the timestamp is valid, otherwise its invalid.
What I wonder now is whether - aside of the actual token itself, I should include additional information to make my timestamps 'long term validation' - proof.
The first thing would be to include the certificates of the trust chain (maybe they cannot be retrieved in 10 years anymore). Then I could also include all current CRLs and OSCP responses for these certificates (that's the same as PAdES does for LTV)
However - since step 3 will require the validator in 10 years to still be able to retrieve revocation information for these certificates anyway (because otherwise he could not determine whether the private key may have leaked) maybe that means including current CRLs and OSCP replies doesn't make sense (since he'll have to know when and why certificates were revoked). Then, does it make sense to include the certificates themselves? If he will be able to query revocation dates and reasons does that imply that he definitely will also be able to retrieve the certificates themselves and thus embedding LTV data together with the token doesn't make sense anyway?
To summarize the question:
- in order to make RFC3161 tokens verifiable long beyond the validity of the TSA certificate, does it make sense to include additional data with the token, and if so, which one and why?
