Digital signatures prove who signed something and that the content has not changed. They do not, by themselves, prove when the signing occurred. The signing certificate’s own validity period tells you when the certificate was active, but it does not prove that a particular signature was created at a specific moment within that period. An unscrupulous party could sign a document today using a certificate that was valid three years ago and claim it was signed three years ago.
Trusted timestamping solves this. A Timestamp Authority (TSA) is an independent third party that receives evidence of a digital signature or document and returns a cryptographically signed token that proves the evidence existed at a specific, verifiable point in time. The token is binding: no one can alter the recorded time after the fact because it is secured by the TSA’s own digital signature.
This capability is essential for three major applications: code signing (so signed software remains trusted after the signing certificate expires), document signing (so signed contracts remain legally valid for years or decades), and intellectual property protection and forensics (proving that a file existed in a specific form at a specific date). This article covers how the mechanism works in detail, including the security properties that make it reliable.
How Trusted Timestamping Works: The RFC 3161 Protocol
RFC 3161, the Time-Stamp Protocol (TSP) published by the IETF in 2001 and updated by RFC 5816 in 2010, defines the standard mechanism for trusted timestamping. The protocol is built on the same Public Key Infrastructure that underlies SSL certificates and digital signatures.
The protocol has four steps:
Step 1: Compute the hash of the content
The client computes a cryptographic hash (SHA-256 or SHA-512 in modern implementations) of the content to be timestamped. For a code signature, this is the hash of the signature value itself. For a document, it is the hash of the document content or the signature. The hash is a fixed-length fingerprint: any change to the content, however small, produces a completely different hash.
Step 2: Construct and send the timestamp request
The client constructs a TimeStampReq (Timestamp Request) message containing: the hash and the hash algorithm identifier, a nonce (a large random number generated specifically for this request), a flag indicating whether the TSA’s certificate should be included in the response, and optionally a policy identifier specifying which TSA policy should govern the timestamp.
The request is sent to the TSA via HTTP, HTTPS, or other transport.
The nonce is a critical security element that most explanations of timestamping skip entirely. The client generates a random number (the nonce) that must appear in the TSA’s response. This proves the TSA processed this specific request and cannot have pre-generated the response or fabricated a timestamp from stored material. The TSA cannot produce a valid timestamp token for a different time than the actual current time because the nonce was generated by the client for this single request.
Step 3: TSA processes the request and generates the token
The TSA receives the request, verifies the request is well-formed, and generates a TimeStampToken (TST) containing: the same hash that was submitted, the current date and time from the TSA’s trusted time source (synchronized against a reliable NTP or atomic clock source), the same nonce that was in the request, the TSA’s policy identifier, a unique serial number for this token, and the TSA’s digital signature over all of this content. Optionally, the TSA’s certificate chain is included.
The TSA never receives or processes the original file, only its hash. This is the zero-knowledge property of trusted timestamping: the TSA can certify when a file existed without ever having access to its contents. A confidential contract, a trade secret, or a sensitive medical record can be timestamped without revealing anything about its content to the TSA.
Step 4: Client embeds and verifies the token
The TSA sends the TimeStampToken back to the client. The client embeds the token in the signed document, alongside the digital signature (for document signing), or attaches it to the signed binary (for code signing). The token is a self-contained cryptographic proof: it includes everything needed to verify it, including the TSA’s certificate chain.
Anyone verifying the timestamp later retrieves the TST, extracts the TSA’s certificate chain, verifies the TSA’s signature over the token content, confirms the nonce matches (or was generated by the requesting system), and reads the certified timestamp value. The verification does not require contacting the TSA or any online service: the token is independently verifiable from the data embedded with the file.
RFC 5816 (2010) updated RFC 3161 to require that the CMS SignedData structure used for the timestamp token explicitly include a signed attribute identifying the signer’s certificate, closing a potential ambiguity about which certificate produced the signature. Modern TSA implementations follow RFC 5816. When evaluating a TSA for compliance-sensitive applications, confirm it follows RFC 5816, not only the original RFC 3161.
What the Timestamp Token Contains
A TimeStampToken is a DER-encoded ASN.1 structure (the .tsr file format when saved as a standalone file). Its contents determine what can be proven in verification:
| Token Field | Content | What It Proves |
| messageImprint | Hash of the content that was submitted plus the hash algorithm identifier | That this specific content (with this specific hash) was submitted to the TSA |
| genTime | The TSA’s certified date and time in UTC, accurate to the TSA’s stated precision | The content existed at or before this timestamp |
| nonce | Echo of the nonce from the TimeStampReq | The TSA generated this token in direct response to this specific request, not from pre-generated or cached material |
| serialNumber | Unique identifier for this specific timestamp token | That this is a unique, specific TSA issuance (not a duplicate or replay) |
| policy | OID of the TSA policy under which the timestamp was issued | Which TSA policy governs this timestamp; relevant for regulatory contexts specifying required policies |
| tsa (optional) | The TSA’s identity | Which TSA issued this token |
| certificates (optional) | The TSA’s certificate chain | Allows offline verification without querying any certificate service |
| TSA signature | The TSA’s digital signature over all above content | All above fields are authentic and have not been modified since the TSA signed them |
Application 1: Code Signing and the Certificate Expiry Problem
The most common reason software developers encounter timestamping is code signing. A code signing certificate has a validity period, typically one to three years. When the certificate expires, a naive verification process would reject all signatures made with it, because the certificate is no longer valid.
This creates an unacceptable operational problem: software signed with a certificate two years ago would become untrusted when the certificate expires, requiring every previously distributed binary to be re-signed with a new certificate. For widely distributed software, firmware updates, driver packages, and any software embedded in devices, re-signing everything is impractical or impossible.
Trusted timestamping solves this at signing time. When software is signed, the signing tool immediately requests an RFC 3161 timestamp for the signature from a TSA. The TSA returns a token proving the signature existed while the certificate was still valid. This token is embedded in the signed file alongside the signature.
When Windows or another platform verifies the signature after the certificate has expired, the verification process checks the timestamp token. The token proves the signature was created during the certificate’s validity period. The signature is considered valid because it was created at a time when the certificate was trustworthy, even though the certificate has since expired.
A signed software file without a timestamp becomes untrusted when the signing certificate expires. This cannot be fixed retroactively: the timestamp must be obtained at the time of signing. Always use timestamping in code signing workflows. For Windows code signing, specify a TSA URL in your signtool command (/tr flag). For other platforms and tools, confirm that timestamping is enabled in your signing configuration. A certificate expiring in two years without timestamps means re-signing all distributed software when it does.
TSA certificates also expire and are rotated. DigiCert, Sectigo, and other TSA operators update their TSA signing certificates at least every 15 months. The timestamp token embeds the TSA’s certificate chain at the time of issuance, which is why old timestamp tokens remain verifiable even after the TSA has rotated to a new certificate. The token is self-contained; it does not depend on the TSA’s current certificate.
Application 2: Document Signing, LTV, and Long-Term Archival
For signed PDF documents, contracts, and legal records, the validity of the signature must often be demonstrable years or decades after the original signing. Digital certificates expire, CAs retire their infrastructure, cryptographic algorithms are eventually deprecated. A document signed with a SHA-1 certificate in 2010 would be unverifiable today under normal circumstances because SHA-1 is no longer trusted.
Long Term Validation (LTV) and Long Term Archival (LTA) are mechanisms, defined by ETSI standards for PDF digital signatures (PAdES, PDF Advanced Electronic Signatures), that use trusted timestamps to preserve verifiability across time.
Long Term Validation (LTV)
LTV embeds all validation material within the signed document at signing time: the full certificate chains for all signers, revocation status information (OCSP responses or CRL data), and a trusted timestamp proving the signatures existed before the certificates expired. This embedded material allows the document to be validated in the future using only information contained within the document itself, without needing to contact the CA’s OCSP server, download current CRLs, or access any live network service.
An LTV-enabled PDF is self-validating: even if the CA that issued the signing certificate has ceased operations, the embedded certificate chain, revocation information, and timestamp collectively prove that the signature was valid when it was made.
Long Term Archival (LTA)
LTA extends LTV by adding archive timestamps: additional timestamps applied periodically to the entire document, including all existing signatures and their LTV validation data. These archive timestamps refresh the proof of integrity and authenticity for the document as a whole.
The practical implication of archive timestamps: as cryptographic algorithms age and their security properties weaken (as SHA-1 weakened and SHA-256 may eventually weaken), archive timestamps applied before the weakening event extend the provable validity of the document into the future, because each archive timestamp is signed with current, strong algorithms at the time it is applied. A document signed in 2025 with SHA-256 that has archive timestamps applied every five years will remain verifiable in 2075 even if SHA-256 has been deprecated by then.
ETSI TS 103 172 defines LTA (Long Term Archival) for PAdES signed PDFs. This standard is what e-signature platforms like DocuSign, Adobe Sign, and Zoho Sign use when they offer ‘long term validity’ options. These platforms partner with qualified TSAs that issue timestamps meeting the ETSI and eIDAS requirements for EU-qualified electronic signatures. If document archival across multi-decade timeframes is a requirement, confirm that your signing platform implements LTA, not just LTV.
Application 3: Intellectual Property and Forensic Evidence
Trusted timestamps provide a mechanism for proving that a document, design, source code file, or creative work existed in a specific form at a specific date, without requiring it to have been filed with any public authority. This has applications in intellectual property protection and digital forensics.
Intellectual property protection
A developer who creates a novel algorithm, an artist who produces an original work, or a company that develops a trade secret can timestamp a hash of the file at the point of creation. The timestamp token, stored alongside the file, proves that the content existed in that form on that date. In a later dispute about who created something first, the timestamp provides cryptographic evidence of the creation date.
The zero-knowledge property is particularly valuable here: the confidential contents of the file are never disclosed to the TSA. The hash reveals nothing about the content. Timestamping a confidential design document or proprietary source code file does not expose the content to any third party.
Digital forensics
In legal proceedings, forensic investigators use trusted timestamps to establish chain-of-custody for digital evidence. A hash of a disk image, a database export, or a log file that is timestamped at the time of collection proves that the evidence existed in that exact form at the collection date and has not been modified since. Timestamped forensic evidence is harder to challenge on integrity grounds than evidence without independent time-binding.
Practical Timestamping: Public TSA Endpoints
Major CAs operate public TSA endpoints under the RFC 3161 protocol. These are typically free to use for timestamping. The most widely used:
| TSA Operator | RFC 3161 Endpoint | Notes |
| DigiCert | http://timestamp.digicert.com | Most widely used for Windows code signing. Recommended in Microsoft documentation. |
| Sectigo | http://timestamp.sectigo.com | Another widely used TSA for code signing. |
| GlobalSign | http://timestamp.globalsign.com/tsa/r6advanced1 | Also offers qualified timestamps for eIDAS compliance. |
| Comodo (via SSL.com) | http://timestamp.ssl.com | Provided by SSL.com’s infrastructure. |
| Sigstore TSA | https://timestamp.sigstore.dev/api/v1/timestamp | Open-source supply chain signing use; RFC 3161 compliant. |
| # Timestamping in signtool (Windows code signing):
# /tr specifies the RFC 3161 timestamp server URL # /td specifies the timestamp digest algorithm (sha256 recommended) signtool sign /fd sha256 /tr http://timestamp.digicert.com /td sha256 /a setup.exe
# Verify a timestamp on a signed file: signtool verify /pa /v setup.exe # Look for ‘Successfully verified’ and the timestamp date in the output. |
Frequently Asked Questions
What is trusted timestamping?
Trusted timestamping is a cryptographic process that proves a piece of digital content existed in a specific form at a specific point in time. A Timestamp Authority (TSA) receives the hash of the content, attaches a certified date and time from a trusted time source, and signs the result. The resulting Timestamp Token is an independently verifiable proof that the content existed before the certified time. No one can alter the timestamp after the fact because it is secured by the TSA’s digital signature. The standard governing this process is RFC 3161.
Why do code signing certificates need timestamps?
Code signing certificates expire. Without a timestamp, software verification checks the certificate’s validity period at the time of verification: if the certificate has expired, the signature is rejected. A trusted timestamp proves that the signature was created while the certificate was valid, even if the certificate has since expired. This allows signed software to remain trusted indefinitely after the signing certificate expires. Adding a timestamp at signing time is a one-time operation that prevents the need to re-sign all distributed software when the certificate renews.
Does the TSA see the content of what I am timestamping?
No. The TSA receives only a cryptographic hash of the content, never the content itself. The hash is a fixed-length fingerprint that reveals nothing about the original file. This zero-knowledge property means you can timestamp confidential contracts, trade secrets, and sensitive documents without disclosing their contents to any third party. The TSA certifies when the hash existed; anyone who later has access to the original file can verify that it matches the hash in the timestamp token.
What is the difference between LTV and LTA for document signing?
Long Term Validation (LTV) embeds all certificate chains, revocation data, and a timestamp in a signed document at signing time, making the document self-validating without requiring network access to CAs or OCSP servers. Long Term Archival (LTA) builds on LTV by adding periodic archive timestamps applied to the entire document including existing LTV data. Archive timestamps extend verifiability as algorithms age: each archive timestamp is produced with current strong algorithms and proves the document’s integrity at a point before the previous algorithms were deprecated. LTA is the appropriate standard for documents that must be verifiable decades into the future.
How do I know a TSA’s timestamp is trustworthy?
RFC 3161 timestamps are trustworthy because the TSA’s signature over the timestamp token is verifiable using standard PKI: the TSA’s signing certificate chains to a trusted CA root, and the TSA’s digital signature proves the token content was produced by the TSA and has not been altered. The nonce in the token proves the TSA produced the token in direct response to the specific request rather than from pre-generated material. For regulated applications requiring qualified timestamps under eIDAS, the TSA must be on the EU Trusted List (ETSI TS 119 612) as an accredited Trust Service Provider, providing regulatory assurance beyond the technical mechanism.
