← Back to all articles

RFC 3161 timestamps explained, how to make a digital signature legally durable

SealDoc Team · · 5 min read

There is a question that comes up the first time someone audits a digital archive: how do you know this document existed on the date it claims? A normal digital signature does not answer that. A signature proves who signed, not when. The signed bytes include a timestamp the signer wrote, but the signer can write any timestamp they want. For most internal use cases that does not matter. For legally-binding archives, tax retention, and chain-of-custody disputes, it matters a lot.

The answer is RFC 3161, the Internet standard that defines a Time-Stamp Protocol (TSP). It is older than most readers expect (published in 2001), it is everywhere in the EU compliance stack, and the way it works is simpler than the acronym makes it sound.

What an RFC 3161 timestamp actually is

An RFC 3161 timestamp is a small signed token issued by a Time-Stamping Authority (TSA). The flow looks like this:

  1. You compute a SHA-256 hash of the document you want to timestamp. The TSA never sees the document itself, just the hash.
  2. You send the hash to a TSA in a TimeStampReq message.
  3. The TSA returns a TimeStampResp containing a TimeStampToken. The token is a CMS structure signed by the TSA’s certificate, and it contains: the hash you sent, the TSA’s claimed time, the TSA’s policy OID, and a cryptographic nonce echoing yours.
  4. You attach the token to your archive, alongside the document.

That token is the timestamp. It says, in cryptographic form, “a TSA whose certificate chains to a trusted root has asserted that this hash existed at this UTC time.” Because the document is identified by hash, you cannot retroactively change the document without invalidating the timestamp. Because the TSA is signing, you cannot retroactively change the time without forging the TSA’s signature.

This is why timestamps are non-repudiable. Both parties (you and any future auditor) can verify the token without contacting the TSA again.

Why a regular timestamp is not enough

The clock on your server is wrong. We say this confidently because every clock everywhere is wrong by some margin, and a court does not care about NTP drift. The legal value of a self-asserted timestamp is roughly the same as the legal value of a hand-written date on a printed receipt: it is suggestive, not probative.

An RFC 3161 timestamp is probative because:

  • The TSA is a regulated entity, audited under standards like ETSI EN 319 421.
  • The TSA’s clock is synchronised against UTC by traceable means (often a national time service or atomic clock reference).
  • The TSA’s certificate is issued by a trusted CA whose root is in the EU Trusted List (LOTL).
  • The timestamp token is verifiable offline by anyone in possession of the TSA’s certificate chain, indefinitely.

The legal framework that makes this enforceable in the EU is eIDAS (Regulation EU 910/2014, revised by 2024/1183). eIDAS defines a “qualified electronic time stamp” as one issued by a TSA on the EU Trusted List. Such a timestamp enjoys the legal presumption of accuracy across all member states. A non-qualified timestamp is still useful, but it does not get the automatic presumption.

Long-term validity, the real reason archives need timestamps

Here is the subtler problem timestamps solve. A digital signature is valid as long as the signer’s certificate is valid. Certificates expire (typically 1 to 3 years), get revoked, or have their issuing CA shut down. Five years from now, the signature on your invoice may be cryptographically intact but legally unverifiable because the trust chain has dissolved.

The fix is to wrap a timestamp around the signature at the moment the signature is still valid. The timestamp proves: “this signature was valid when applied.” Even if the certificate later expires, the cryptographic record of its valid state is preserved. This is the principle behind PAdES Long-Term Validation (LTV) and CAdES-A profiles.

For PDF/A-3 archival, the practical structure is:

  1. Create the PDF/A-3 with the embedded XML invoice.
  2. Apply a digital signature.
  3. Apply an RFC 3161 timestamp to the signature.
  4. Optionally re-timestamp every few years before any TSA certificate in the chain expires (this is what “archival timestamping” means).

A correctly-archived invoice has at least the first three steps. The fourth is what makes a 30-year archive work without intervention every certificate-rotation cycle.

Verifying a timestamp yourself

You do not have to trust the TSA more than the cryptography requires. Verifying a timestamp involves:

  1. Parse the TimeStampToken (CMS structure, ASN.1).
  2. Extract the message imprint (hash + algorithm).
  3. Compute the hash of the document yourself with the same algorithm. Compare.
  4. Verify the TSA’s signature on the token using the TSA’s certificate.
  5. Verify the TSA’s certificate chains to a trusted root, and was valid at the timestamp’s claimed time.
  6. Optionally, check the TSA’s certificate against revocation data captured at archival time.

OpenSSL can do all of this from the command line (openssl ts -verify -in token.tsr -data file.pdf -CAfile chain.pem). It is not a black box.

Where SealDoc fits in

When the SealDoc pipeline produces a PDF/A-3 invoice, it does the timestamp step automatically. The evidence pack we generate alongside every issued invoice contains:

  • The PDF/A-3 file with the embedded XML.
  • The detached RFC 3161 timestamp token.
  • A manifest with SHA-256 hashes of every artefact in the pack.
  • The TSA certificate chain at issuance time, captured for offline verification later.

That is enough to satisfy a tax audit anywhere in the EU, regardless of whether the auditor has internet access to the original TSA. You can re-verify the entire pack offline using OpenSSL or any PAdES-aware library. The Factur-X file inside is independently checkable at /check, and the timestamp is independently checkable with the tools every auditor already has on their machine.

The takeaway

A digital signature without a trusted timestamp is a signature with a deniable date. An RFC 3161 timestamp from an EU-listed TSA turns that into a legally durable record, verifiable offline, valid for decades. If you are archiving structured invoices for the 7-to-10 year window most EU tax laws require, this is not an optional layer. It is the layer that makes the archive worth having.

← Back to all articles