As much as we would want them to, timestamps don’t last forever. With evidence records, there is a way to allow for long-term non-repudiation of the existence of data, even if the original timestamp expires.
Cryptographic timestamps are often assumed to last forever. Aside from issues around changes in algorithm security, which mean they do not stay secure forever, there is also the problem that when the original Timestamp Protocol standard, RFC 3161, was released in 2001, forever was regarded as 20 to 30 years and we are now in 2022. For some it seems that forever has arrived, and for others it is not far away.
An evidence record is a structure designed to support long-term non-repudiation of the existence of data, where a timestamp needs to be meaningful long after its original expiry date. The structure of evidence records, as well as how to generate and validate them, is described in RFC 4998, “Evidence Record Syntax (ERS)”.
Get Started with Evidence Records in Bouncy Castle
Bouncy Castle 1.72 now provides for renewal of timestamps in evidence records as well as hash algorithm upgrades. In addition, support for multiple documents is available which allows a group of documents, or even a group of grouped documents to be collected under a single timestamp via the use of a Merkle tree structure as described in RFC 4998 with additional clarifications described in RFC 6283.
Further work is also planned on this API to allow developers to configure what hash algorithms are acceptable and what expiry dates should be specified. We welcome any feedback on the expanded APIs. Post your comments on GitHub Discussions.
The ERS API is provided in the bcpkix jar and can be found in the org.bouncycastle.tsp.ers package. There are examples of use for single and multiple documents available in org.bouncycastle.tsp.test.ERSTest.
For more information
Here you can find more information to get started:
