Timestamps and trusted time

Spec Spec: RFC 3161 RFC 3161 Spec Spec: RFC 5816 RFC 5816 Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 Evidence § Standard-backed Evidence: Standard-backed

At a glance

A timestamp does not record “when this was signed.” It proves something narrower and stronger. It proves that a specific piece of data existed before a specific instant, attested by a party who is not the signer. That distinction is the entire value of trusted time, and it is often misunderstood.

Why this matters

The signing time inside a signature is whatever the signer’s computer claimed. A clock can be wrong by accident or by intent. If the only evidence of when is the signer’s own assertion, then a signer can predate or postdate a document at will. A certificate that was revoked yesterday can be made to look as if it signed last year. “When” is not a detail. It decides whether a signature made with a now-expired or now-revoked certificate still counts. And if trusted time is wrong, every long-term validity argument built on top of it collapses.

The short version

• A signer’s own signing time is a claim, not proof. It is trivially forgeable.
• An RFC 3161 timestamp is a signed token from a Time-Stamp Authority (TSA) binding a hash of your data to the TSA’s time.
• What it proves is precise: the data existed before the TSA’s stated time. Not the exact creation moment — an upper bound.
• The token echoes your nonce and your message imprint, so it cannot be a replay and cannot be about different data.
• A document timestamp applies the same mechanism to the whole PDF, anchoring everything beneath it — the signature and its embedded validation evidence — to a trusted instant.

How NextPDF approaches it

NextPDF treats a timestamp as something to verify, not merely to obtain. Requesting a token is the smaller part of the work. The engine’s stance is that an unverified token is not evidence.

When the engine timestamps a signature, it sends the TSA a hash of the data and a fresh random nonce, never the data itself. The returned token is then checked against the full set of properties that make it meaningful: the authority’s status was “granted”, the nonce in the token matches the one sent, the message imprint in the token matches the hash sent, the token’s own cryptographic signature verifies, the token’s content type is the timestamp type, and the stated time falls inside an acceptable tolerance. Any divergence is a hard failure with a typed reason. There is no “looks close enough” path. A document timestamp follows the same rule, applied to the whole file rather than one signature’s value.

1. Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
2. Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
3. TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
4. Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
5. Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

How a trusted timestamp is obtained and what it proves: a hash plus a nonce is sent to the TSA, the TSA returns a signed token binding that hash to its time, and the verifier confirms the binding before treating it as proof that the data existed before that time.

What the evidence says

Evidence § Standard-backed Evidence: Standard-backed The definition is exact. Spec Spec: ISO/IEC 18014-2, §3 ISO/IEC 18014-2 §3 defines a time-stamp service as one that provides evidence that a data item existed before a certain point in time — an upper bound, not a creation instant. Spec Spec: ISO/IEC 18014-2, §7 ISO/IEC 18014-2 §7 defines the token’s TSTInfo content: a message imprint (the hash of your data), a generation time, a serial number, and an optional nonce. Spec Spec: ISO/IEC 18014-2, §6 ISO/IEC 18014-2 §6 states the conclusion a verifier may draw on success: that the data item existed before the time in the token — nothing more and nothing less.

For PDF, Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 specifies the document timestamp: the byte range covers the whole file excluding the Contents value, that hash is sent to a timestamp authority, and the returned RFC 3161 token — as updated by Spec Spec: RFC 5816 RFC 5816 — is placed in Contents. The same byte-range discipline as a signature, applied to time instead of identity. And Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 is why this matters for longevity: trusted time is what lets a validator prove a signature was reliable on the day it was produced even after the certificate expired.

NextPDF’s engine sends a hash and a nonce, never the data, and verifies the returned token against status, nonce, message imprint, token signature, content type, and time tolerance before treating it as evidence.

Human-factors note: Human-factors note

The page leads with the precise claim — a timestamp proves data existed before a time, by a third party — because the most common and most expensive error here is overstating it as “proof of the exact signing moment.” Stating the true, narrower claim first is the warning that prevents the misuse, placed ahead of the mechanism.

Practical example

You do not assemble a timestamp token by hand. What matters is the trust seam. A TSA is something you configure and protect, because its time becomes your evidence.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

The important seam is that the engine sends a hash, not the document, so the TSA never sees your content. And it verifies the response. A TSA you cannot authenticate is not trusted time. It is only another clock.

Common misconception

The trap is reading a timestamp as “this was signed at exactly 14:32 on this date.” It is not a stopwatch on the signing event. It proves the data existed no later than the TSA’s time, which is an upper bound set by a third party. The creation could have been any time before that. A second trap is assuming any timestamp server gives you trusted time. A token whose signature you cannot verify, or whose authority you do not trust, proves nothing. It is a clock you have no reason to believe. Trusted time comes from a TSA you can authenticate and a token you have verified, not from the act of asking a server for a number.

Limits and boundaries

NextPDF builds the request, sends only a hash, and verifies the returned token. It does not vouch for the authority behind it. The TSA’s accuracy, its own certificate’s validity, and its trustworthiness are properties of the service and of your deployment’s configuration, not of the engine. A timestamp binds a hash to a time. It says nothing about the meaning of the data, the identity of the signer, or whether the signer’s certificate was valid. Those are separate checks covered in Validating a signature properly. The engine cannot make an untrustworthy TSA trustworthy. This page also does not assert any specific legal weight for a timestamp; that depends on the TSA’s status and the jurisdiction. How trusted time is reused to keep a signature verifiable over decades is covered in Long-term validation.

Tier availability of timestamping:

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T — a verified RFC 3161 timestamp on the signature value, against a deployment-supplied TSA.
Enterprise	○ Adds the document timestamp used by B-LT and B-LTA to anchor embedded validation evidence and to drive the archival renewal loop.

Related docs

• Long-term validation — how the document timestamp seals embedded evidence and is renewed over time.
• PAdES baseline profiles — where the signature timestamp (B-T) and document timestamp (B-LTA) sit in the level progression.
• Qualified signatures, explained — where a qualified timestamp fits in the eIDAS trust picture.

Glossary

• Timestamp (RFC 3161) — a signed token from a TSA binding a hash of data to the TSA’s time, proving the data existed before that time.
• Time-Stamp Authority (TSA) — the trusted service that issues timestamp tokens.
• TSTInfo — the token’s content structure: message imprint, generation time, serial number, and optional nonce.
• Message imprint — the hash of the data being timestamped, echoed in the token.
• Nonce — a fresh random value sent with the request and echoed in the token, so the response cannot be a replay.
• Document timestamp — an RFC 3161 timestamp over the whole PDF (as updated by RFC 5816), anchoring the signature and its evidence to a trusted instant.