What Is an RFC 3161 Timestamp?

An RFC 3161 timestamp is a small signed token from a trusted Time Stamping Authority (TSA) that proves a piece of data existed at a certain time. It follows RFC 3161, the IETF Time-Stamp Protocol, and anyone can check it later without trusting the person who holds the data.

Why trusted timestamps matter

A computer clock can be set to any time, and a date typed into a file proves nothing. A trusted timestamp comes from an independent TSA, which signs the time with its own key.

Later, anyone can check two things: when the data existed, and that it has not changed since. Common uses include:

  • Keeping digital signatures valid after the signer’s certificate expires or is revoked (long-term validation)
  • Code signing, so signed software stays valid after the code signing certificate expires
  • Contracts, invoices, and legal and medical records
  • Evidence of when a design, a lab result or a log entry existed

How RFC 3161 works

RFC 3161, published by the IETF in August 2001, defines a simple request and response flow:

  1. Hash the data. The client computes a hash of the file, for example with SHA-256. Only the hash is sent, so the TSA never sees the document itself.
  2. Send a request. The client sends a time-stamp request with the hash. It can add a random number (a nonce) to match the reply to the request. Requests are often sent over HTTP.
  3. The TSA signs. The TSA adds the current time from a trusted clock, a serial number and its policy ID, and signs all of this with its private key.
  4. Get the token. The TSA returns a time-stamp token. The client stores it with the data.
  5. Verify at any time. Anyone can hash the data again and compare it with the hash in the token, then check the TSA’s signature and certificate chain.

What is inside a timestamp token

  • The hash of the data and the hash algorithm used
  • The time (called genTime), in UTC
  • The TSA’s policy identifier
  • A unique serial number
  • The nonce, if the client sent one
  • Optionally, the accuracy of the time
  • The TSA’s digital signature

The token uses the CMS signed-data format. The TSA’s certificate must be issued for timestamping only: it carries the extended key usage “timeStamping”, marked as critical.

Try it with OpenSSL

Developers can create a request and check a response with standard OpenSSL commands. Set TSA_URL to the address of the TSA you use.

openssl ts -query -data contract.pdf -sha256 -cert -out contract.tsq
curl -H "Content-Type: application/timestamp-query" --data-binary @contract.tsq "$TSA_URL" -o contract.tsr
openssl ts -verify -data contract.pdf -in contract.tsr -CAfile tsa-chain.pem

The first command hashes the file and builds the request. The last command checks the token against the file and the TSA’s certificate chain.

Related standards

  • RFC 5816 (March 2010) updates RFC 3161. It lets the TSA’s certificate be identified with SHA-256 and other modern hashes, not only SHA-1.
  • ETSI EN 319 421 sets policy and security requirements for trust service providers that issue time-stamps.
  • ETSI EN 319 422 profiles the time-stamping protocol and the token, based on RFC 3161.
  • eIDAS: in the EU, a qualified electronic time stamp from a qualified trust service provider is presumed to have an accurate date and time and intact data (Article 41 of Regulation (EU) No 910/2014). See what a qualified trust service provider is.
  • Signature formats: PAdES (PDF), CAdES and XAdES use RFC 3161 tokens in their long-term levels.

What a timestamp does not prove

  • It does not prove who created the data.
  • It does not prove that the content is true.
  • It is only as trustworthy as the TSA: its clock, its key protection and its policies. This is why TSA signing keys are usually kept in a hardware security module (HSM) and the TSA clock is synchronized with UTC.

How DictaLabs helps

DictaLabs TSA issues cryptographically signed timestamps that give trusted evidence of when digital data existed. It is designed around RFC 3161, RFC 5816 and ETSI EN 319 421/422.

Its flow matches the steps above: the client sends a hash, the TSA applies its timestamp policy with trusted time, signs the token and returns it, and the token can be verified at any time. TSA signing keys are protected by HSMs, and the design uses redundant TSA nodes with load balancing and failover.

It works with Adobe Acrobat, SignTool, jarsigner and document-signing platforms, with CA/CLM, document management and workflow systems, and with RFC 3161 over HTTP/HTTPS, REST/API and OpenSSL. For signing workflows, vScrawl adds PDF signing with tamper detection and long-term validation support.

Organizations that plan to run timestamping as a trust service of their own can get architecture, documentation and audit-readiness support through DictaLabs trust service provider consulting.

Next step

Need trusted timestamps in your signing or records workflow? Contact the DictaLabs team.

Related