Trusted Timestamp (TSA)

Short definition

A trusted timestamp in the cryptographic sense is a signed attestation from a trusted third party — the Time Stamping Authority (TSA) — that a given piece of data (usually the hash of a document) existed at a specific moment. The protocol is standardised in RFC 3161, with the European long-term variant in RFC 5816.

Without a timestamp, a digital signature only states: “this document was signed by this person” — but not when. With a timestamp, the document becomes an audit-safe proof: “this document existed no later than this time”.

How a TSA works

1. The client computes the hash of the document (e.g. SHA-256)
2. The client sends the hash as a TimeStampReq to the TSA
3. The TSA combines the hash with its current time from a synchronised reference
4. The TSA signs the bundle with its timestamp certificate
5. The client receives the TimeStampResp and embeds it alongside the document

The key property: the TSA never sees the document — only its hash. Privacy and minimalism are baked into the protocol.

Qualified vs. plain timestamps

Like signatures, eIDAS defines two trust levels:

	Plain timestamp	Qualified timestamp
Standard	RFC 3161	RFC 3161 + eIDAS Art. 41/42
TSA requirements	none formal	listed in the EU Trusted List
Presumption of correctness	no	yes (date and integrity)
Use	internal proofs	audit-safe archives, QES

For PAdES-B-LT and -LTA as well as for the long-term validity of qualified signatures, the qualified timestamp is the right choice.

Why timestamps matter for long-term validation

A signing certificate is typically valid for 1–3 years. After that the signature does not automatically collapse — but its verifiability depends on being able to prove the certificate was still valid at the time of signing. The timestamp delivers exactly that proof.

In PAdES-B-LTA an additional archive timestamp is placed periodically over the whole document (including existing signatures and validation data) — keeping the chain closable for decades, even as individual crypto algorithms age out.

With the Dokmatiq API

For every PAdES signature at profile PAdES-B-T or higher, a qualified timestamp is requested automatically:

curl -X POST https://api.dokmatiq.com/v1/pdf/sign \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@invoice.pdf" \
  -F "certificate=@signing.p12" \
  -F "passphrase=..." \
  -F "profile=PAdES-B-LT" \
  -F "tsa=qualified" \
  -o signed.pdf

Alternatively a document can be timestamp-only — without a content signature — to establish proof of existence:

curl -X POST https://api.dokmatiq.com/v1/pdf/timestamp \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  --data-binary "@document.pdf" \
  -o timestamped.pdf

That pattern is useful for engineering documentation, research data or design drafts where you later want to prove: “this idea/design existed at that point”.

Common pitfalls

1. TSA certificate expired — the timestamp issuer has its own certificate lifetime. PAdES-B-LTA refreshes periodically; plain TSA stamps age out with their certificate
2. Weak hash algorithm — SHA-1 timestamps should no longer be issued or accepted; SHA-256 or -512 are standard
3. Clock drift — the client’s clock is irrelevant; the TSA’s time counts. Systems that compare both often stumble over DST and time zones
4. Confusing plain with qualified — any RFC 3161 service does not automatically satisfy the eIDAS presumption