What files and supporting information should I preserve alongside a timestamp certificate?

Preserve the exact certified version

Keep the files in the form they had when certified. A cryptographic fingerprint depends on the file’s contents, as explained by NIST. A document that looks identical after being opened and saved may contain different bytes and no longer match its certificate.

For examples of how everyday software can alter files without an explicit save, see Your certificate is immutable. Your files are not..

Work on copies when making changes. Keep useful exports or converted formats as additional copies, clearly distinguished from the certified originals. If you certified a ZIP archive, preserve that exact archive: rebuilding a ZIP from the same documents can produce a different file.

Check what the certificate covers. If it refers to a package of files or a manifest listing their fingerprints, retain that structure and the information connecting each file to the certificate. A filename alone is not a reliable identifier of a version.

Keep the verification material, not just a picture of the certificate

Download the original certificate and any accompanying proof files or validation package. A screenshot or printout may show the date and a reference number while omitting the digital data needed to verify them. A PDF may contain useful verification data, so retain the original PDF rather than a scan of it.

The material required depends on the timestamping method. For an RFC 3161 timestamp, verification involves the timestamp token, the file’s fingerprint, the authority’s signature and relevant certificate information. Section 2.2 of RFC 3161 describes those checks. Keep the provider’s export and verification instructions, and check whether further validation material is needed for long-term preservation.

Test the exported package while you still have access to the service. Record when the check was performed, the tool used and its result. This helps the next person repeat the process, although a past successful check does not replace verification of the files presented later.

Explain what the certified material represents

A short note should let someone unfamiliar with the project understand the record. Include:

• The project and the version or milestone covered.
• What the files contain and why this version was certified.
• Who contributed and who prepared the record.
• The dates of the work, distinguished from the certification date.
• Where the files, certificates and supporting records are stored.

Retain relevant briefs, contracts, contribution confirmations, test results and correspondence. For example, if the certified drawing was sent to a manufacturer, keep the message identifying the delivered version and the terms governing that disclosure. The certificate supports the dated existence of the drawing; those other records help explain its use and significance.

Make the records recoverable

Maintain backups in a separate location and periodically check that you can retrieve the files and verify them. If storage is encrypted, keep recovery information securely under the control of someone responsible for the records. Do not put decryption secrets into a package you routinely share.

Assign responsibility for keeping the records accessible when a contributor leaves or a service account closes. When moving to new storage, check the copied files against their recorded fingerprints. Keep the original certified version even if you also create a newer format for reading it.

A certificate cannot reconstruct a missing file, restore an altered file to its certified version or unlock one whose key is lost. Preserving the files and the means to access them is part of preserving the evidence.