How RFC 3161 Timestamping Proves When a Document Was Signed

An RFC 3161 timestamp is a small token, signed by a trusted Time Stamping Authority (TSA), that binds the hash of a document to a specific date and time. Anyone can later check the TSA’s signature to prove the document existed in exactly that form at that moment, even after the signer’s own certificate has expired.

Why a signature alone does not prove when something was signed

The time shown in an ordinary digital signature usually comes from the signer’s own computer. That clock can be wrong, or it can be changed.

Signing certificates also expire or get revoked. Without trusted time, nobody can show that a signature was made while the certificate was still valid.

A timestamp from an independent TSA solves both problems.

What is RFC 3161?

RFC 3161, the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), is the IETF standard published in August 2001. It defines the request a client sends and the signed token the TSA returns.

RFC 5816, published in March 2010, updates it so the TSA’s certificate can be identified with SHA-2 hashes (ESSCertIDv2) instead of only SHA-1.

In Europe, ETSI EN 319 421 sets the policy and security requirements for trust service providers that issue timestamps, and ETSI EN 319 422 defines the timestamping protocol and token profile.

How it works, step by step

1. Submit a request. The client hashes the document, for example with SHA-256, and sends only the hash, usually with a random number called a nonce. The TSA never sees the document itself.
2. Validate and process. The TSA checks the request and takes the current time from its trusted clock.
3. Issue the timestamp. The TSA signs a token that contains the hash, the time, a unique serial number and the identifier of the policy it followed, and returns it to the client.
4. Verify any time. Later, anyone can hash the document again, compare the result with the hash in the token, and check the TSA’s signature and certificate chain.

In short: document, then hash, then TSA, then signed token, then verifier. If even one byte of the document changes, the hashes no longer match.

What makes a timestamp trustworthy

• Accurate time. The TSA’s clock should be traceable to Coordinated Universal Time (UTC).
• A protected signing key. The TSA’s private key should live in a hardware security module (HSM). RFC 3161 also requires a key reserved only for timestamping.
• A dedicated certificate. RFC 3161 requires the TSA certificate to carry the extended key usage id-kp-timeStamping, and that extension must be marked critical.
• Policy and availability. A published policy, audit logs and high availability matter. A TSA that is down on signing day blocks the whole workflow.

Where timestamps are used

PDF signatures. A signature timestamp keeps a PDF signature verifiable after the signing certificate expires. The PAdES baseline profiles in ETSI EN 319 142-1 build on this: the B-T level adds a signature timestamp, and the B-LT and B-LTA levels add validation data and further timestamps for long-term validation. Signing platforms such as vScrawl, our digital signature and workflow platform, list long-term validation support for signed PDFs.

Code signing. Microsoft SignTool and Java jarsigner can add an RFC 3161 timestamp when signing, so signed software can stay valid after the code signing certificate expires.

Records, logs and archives. A timestamp proves that a file, log or invoice has not changed since a given moment.

Evidence and regulated records. Legal and e-discovery teams, financial services and government records all need to show when something existed and that it was not altered.

Qualified timestamps under eIDAS

Under Article 41 of the eIDAS Regulation (EU) No 910/2014, an electronic timestamp cannot be denied legal effect or admissibility as evidence just because it is electronic or is not qualified. A qualified electronic timestamp also enjoys a presumption that its date and time, and the integrity of the data bound to them, are accurate.

Article 42 sets the requirements for qualified timestamps. The binding must make undetected changes to the data reasonably impossible, the time source must be linked to UTC, and the token must be signed or sealed by the qualified trust service provider (QTSP), or protected by an equivalent method.

Only a QTSP can issue qualified timestamps. Our checklist for becoming a QTSP under eIDAS 2.0 explains how a provider gets that status, and our trust service provider consulting covers the design of timestamping and validation services.

Try it yourself with OpenSSL

These four commands show the full flow. Replace tsa.example.com with the address of the TSA you use, and tsa-ca-chain.pem with that TSA’s CA certificates.

openssl ts -query -data contract.pdf -sha256 -cert -out request.tsq
curl -H "Content-Type: application/timestamp-query" --data-binary @request.tsq https://tsa.example.com/ -o response.tsr
openssl ts -reply -in response.tsr -text
openssl ts -verify -data contract.pdf -in response.tsr -CAfile tsa-ca-chain.pem

• Line 1 hashes contract.pdf with SHA-256 and builds a request. The -cert option asks the TSA to include its certificate in the reply, and OpenSSL adds a nonce by default.
• Line 2 sends the request over HTTP with the content type that RFC 3161 defines, and saves the reply.
• Line 3 prints the token in readable form: status, policy, hash, serial number, time and nonce.
• Line 4 checks that the token matches the file and that the TSA’s signature chains to the CA certificates you trust.

Checklist for choosing a TSA

• Which standards does it follow: RFC 3161, RFC 5816, ETSI EN 319 421 and ETSI EN 319 422?
• Is it qualified under eIDAS, if your use case needs qualified timestamps?
• How is the signing key protected, and what are the time source and accuracy?
• What uptime, redundancy and support does it offer?
• Can it run where you need it, for example inside your own network?

How DictaLabs TSA fits

DictaLabs TSA, our trusted timestamping authority, issues cryptographically signed timestamps that provide trusted evidence of when digital data existed. Its product page lists:

• A design built around RFC 3161, RFC 5816 and ETSI EN 319 421/422.
• TSA signing keys protected by hardware security modules.
• Redundant TSA nodes with load balancing and failover.
• An audit trail of timestamp transactions, security events and system activity.
• Integration with Adobe Acrobat, SignTool, jarsigner and document-signing platforms, with CA/CLM, document management and workflow systems, and developer access over HTTP/HTTPS, REST APIs and OpenSSL.

Next step

If you need trusted timestamps for signatures, code or records, contact our TSA experts to talk through your requirements.