Trusted time: how a timestamp proves when

SpecSpec: RFC 3161RFC 3161SpecSpec: RFC 5816RFC 5816SpecSpec: ISO 32000-2, §12.8.5ISO 32000-2 §12.8.5

At a glance

A timestamp answers a single, surprisingly slippery question: did this data exist yet? Not who made it, not whether it is correct — only that, at some named instant, these exact bytes were already in the world. This page builds the idea from the ground up: what a Time-Stamp Authority does, what a token actually contains, and why a number on a clock becomes evidence.

It is the first-principles companion to the engine-focused Timestamps and trusted time. Read this one first if “trusted time” sounds like jargon.

Why this matters

Your computer’s clock is a confession, not proof. You can set it to any value you like, and so can anyone else. The moment a date matters to a second party — a contract that had to be signed before a deadline, a record that had to exist before a dispute — your own clock is worthless as evidence, because you control it. The whole problem of trusted time is finding a clock you cannot move.

This is not a niche concern. Every long-lived signed PDF leans on it. A signing certificate eventually expires; years later, a verifier needs to know the signature was made while the certificate was still valid. Without an independent record of “when,” that question has no honest answer. Trusted time is the quiet foundation the whole edifice of durable signatures rests on.

The short version

• A timestamp proves a piece of data existed before a stated instant. That is an upper bound on age, nothing more.
• It is produced by a third party, the Time-Stamp Authority (TSA), whose clock you trust precisely because it is not yours.
• The TSA never sees your data. It signs a hash of it, bound to a time value, and returns a small signed token.
• The token proves three things together: the data is the data (the hash matches), the time is the TSA’s time (its signature), and the reply matches the request you sent (the nonce it echoes back, guarding against a replayed older response).
• It does not prove who wrote the data, that the data is true, or the exact moment of creation. Only: not later than this.
• Trust flows to the TSA. A publicly-trusted TSA is good enough for most records; an eIDAS-qualified TSA carries a legal presumption in the EU.

How NextPDF approaches it

Start with the trick at the centre of it all. You want a stranger to vouch for when your data existed, but you cannot show them the data — it may be confidential, and in any case it could be enormous. So you do not. You compute a hash: a short, fixed-length fingerprint that changes completely if even one byte of the original changes, and from which the original cannot be recovered. You send the fingerprint, not the file.

The TSA takes that fingerprint, attaches its own current time, signs the pair with its private key, and hands back a time-stamp token (SpecSpec: RFC 3161, §2.1RFC 3161 §2.1). The token is the binding made permanent: this fingerprint, at this time, vouched for by me. Because the token is signed, nobody — not even the TSA afterward — can alter the time without breaking the signature. Because it carries your fingerprint, it is useless for any other file. And because the request includes a fresh random nonce that the TSA echoes back unchanged, you can tell the reply corresponds to this particular request and is not a replay of an older response — the nonce attests freshness, not who asked (SpecSpec: RFC 3161, §2.4.2RFC 3161 §2.4.2).

Think of a wax seal pressed over a folded letter. The seal does not read the letter; it just proves the letter was whole and present when the seal was struck. A timestamp is a seal struck by a clock you do not own, over a fingerprint of your data.

1. Fingerprint the dataCompute a one-way hash of the file or the signature value. The data itself never leaves your hands.
2. Ask the authoritySend the hash and a fresh random nonce to the Time-Stamp Authority.
3. The TSA seals a timeIt signs the hash bound to its own clock and echoes your nonce, producing a small signed token.
4. Store the tokenFor a PDF, the token is placed inside the file so the proof travels with the document.
5. Verify laterAnyone who trusts the TSA can check the token: its signature against the TSA certificate, the matching hash, the echoed nonce, and the time — then concludes an upper bound on age.

How a trusted timestamp is obtained and what it proves: a hash plus a fresh nonce go to the TSA, the TSA signs that hash bound to its own time and echoes the nonce, and the verifier checks every link before treating the token as proof that the data existed before the stated time.

In a PDF, this same mechanism wears two hats. A signature timestamp seals when a signature was applied, by timestamping the signature’s value. A document timestamp seals when the whole file existed, by hashing the entire PDF (excluding the placeholder the token will occupy) and storing the returned token back in that placeholder (SpecSpec: ISO 32000-2, §12.8.5ISO 32000-2 §12.8.5). The second kind is what a long-lived archival signature renews over the years to keep its trust fresh.

One modern detail worth knowing: an older timestamp format pinned itself to one hash algorithm for naming the TSA’s own certificate. The updated profile lets a token name its certificate with a current digest instead (SpecSpec: RFC 5816, §2.1RFC 5816 §2.1), so trusted time does not quietly inherit yesterday’s cryptography.

Practical example

You do not hand-assemble a token, and you should not want to. The thing worth understanding is the seam of trust: which clock you are choosing to believe. In NextPDF, asking for a signature level that needs trusted time makes that choice explicit rather than implicit.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// A baseline signature trusts only the signer's own clock.
$baseline = SignatureLevel::PAdES_B_B;
$baseline->requiresTimestamp(); // false → no third party vouches for "when"

// Stepping up to B-T means a Time-Stamp Authority must be supplied:
// from here on, "when" is attested by a clock you do not control.
$timestamped = SignatureLevel::PAdES_B_T;
$timestamped->requiresTimestamp(); // true → a TSA is now part of your trust model

// The decision is now visible at the call site, not buried in a default.
// Choosing the TSA is choosing whose time becomes your evidence.

The point of the example is not the API. It is that “do I have trusted time?” is a yes-or-no fact about your document, decided by whether a TSA was in the loop — and the engine refuses to let that fact be ambiguous.

Common misconception

The trap is reading a timestamp as “this was created at 14:32.” It says no such thing. It says “this existed no later than 14:32.” The difference is the whole point. A timestamp is an upper bound, never a lower bound and never an exact moment. Your data could have existed for years before you got around to timestamping it; the token is silent on that. It draws one line and says: not after here.

A second, costlier misconception: that a timestamp proves your document is genuine or correct. It does neither. It is indifferent to meaning. A perfectly timestamped lie is still a lie — now provably old. Authenticity comes from the signature that says who; truth comes from the world. The timestamp only ever speaks to when.

Human-factors note:Human-factors note

Trusted time is a trust decision dressed as a technical one. The instant you accept a timestamp, you have decided to believe a stranger’s clock. That is not a flaw — it is the entire mechanism. The honest question is never “is this timestamp valid,” but “do I trust the authority that issued it, for the purpose I am using it.” A publicly-trusted TSA is ample for most operational records. A qualified one carries legal weight. Naming that choice out loud, instead of inheriting whatever clock happened to be nearest, is the difference between evidence and decoration.

Limits and boundaries

A timestamp’s reach stops exactly where its trust model does. It proves an upper bound on age, and only that, and only if you trust the authority that sealed it.

There are two tiers of authority worth distinguishing. A publicly-trusted TSA chains to a certificate your software already accepts; its tokens are widely verifiable and fine for most records. An eIDAS-qualified TSA is a supervised provider on an EU trusted list, and a qualified electronic timestamp carries a legal presumption of the accuracy of its date and the integrity of the data — a presumption an ordinary timestamp does not (SpecSpec: eIDAS, Art. 41eIDAS Art. 41). Choosing between them is a question about the evidentiary weight you need, not about how the bytes work; the cryptography is the same.

A timestamp also inherits the lifespan of its own trust anchors. The TSA’s certificate can expire or be revoked, and the hash algorithm it used can age out. That is precisely why long-lived documents do not timestamp once and walk away — they renew, layering a fresh document timestamp over the old evidence before the old evidence weakens. That renewal loop is its own subject; see Long-term validation.

RFC 3161 trusted timestamping (signature and document timestamps) — edition availability

Edition	Availability
Core	○ Supports PAdES B-B and B-T. B-B is the baseline signature with no timestamp; B-T requests and embeds a verified RFC 3161 signature timestamp against a deployment-supplied TSA whose clock you choose.
Pro	○ Adds the embedded long-term validation data (certificates, OCSP, CRLs) that B-LT needs to keep a signature verifiable after its certificates expire.
Enterprise	○ Adds the B-LTA renewal loop, sealing the validation data under a fresh document timestamp and re-stamping it before the protection weakens.

Related docs

• Timestamps and trusted time — the same mechanism at the engine and PAdES level, with the verification rules spelled out.
• Long-term validation — how renewing document timestamps keeps a signature verifiable for years.
• How a signature proves who signed — the “who” half of the story this page leaves to one side.
• Qualified signatures explained — what “qualified” means, and why a qualified TSA carries legal weight.

Glossary

• Time-Stamp Authority (TSA) — an independent service that issues signed timestamp tokens. You trust its clock precisely because it is not yours.
• Time-stamp token — the small signed object a TSA returns, binding a hash of your data to a time value (SpecSpec: RFC 3161, §2.1RFC 3161 §2.1).
• Hash (message imprint) — a short one-way fingerprint of the data. The TSA signs this, never the data itself, so your content stays private.
• Nonce — a fresh random number sent with the request and echoed unchanged in the reply, showing the token corresponds to that specific request and is not a replayed old response (it attests freshness, not the requester’s identity).
• Upper bound — what a timestamp establishes: the data existed no later than the stated instant. Never an exact creation moment.
• eIDAS-qualified timestamp — a timestamp from a supervised EU provider that carries a legal presumption of date accuracy and data integrity.
• Document timestamp — a timestamp over an entire PDF file, used to anchor and renew long-term validation evidence (SpecSpec: ISO 32000-2, §12.8.5ISO 32000-2 §12.8.5).