Long-term validation

Spec: ETSI EN 319 142-1 Spec: RFC 6960 Spec: ISO 32000-2, §12.8.4 Evidence: Standard-backed

At a glance

A signature you verify today rests on facts that do not last: a certificate that expires, revocation servers that go offline, and hash algorithms that weaken. Long-term validation records the evidence in the document while it is still obtainable. The signature can then be checked years later without asking anyone anything.

Why this matters

The dangerous property of a digital signature is that it can silently stop being verifiable while looking unchanged. Nothing in the file alters. The certificate authority stops answering questions about a long-expired certificate. A validator that needed that answer can no longer get it. A contract that was unquestionably valid the day it was signed becomes “unable to determine” a decade later. A decade later is exactly when a dispute is most likely and the stakes are highest. If your retention obligation is measured in years, a signature without long-term validation is a risk that surfaces only later.

The short version

A signature’s validity depends on time-sensitive external facts: the certificate’s validity window, and revocation status from a server.
Those facts become unobtainable after the certificate expires — authorities are not obliged to answer forever.
Long-term validation captures the evidence at signing time — certificates, OCSP responses, CRLs — and embeds it in the document’s Document Security Store (DSS).
A document timestamp then proves the evidence itself existed and was valid at that moment, and can be renewed before its own protection weakens.
The result: the document carries its own proof. Verification no longer depends on a server still being there.

How NextPDF approaches it

The principle is “gather the proof while you still can, then seal it.” When NextPDF produces a long-term signature it collects the certificate chain and the revocation responses that prove the signing certificate was good at the moment of signing. It writes them into the DSS as embedded values rather than links. It then adds a document timestamp over the whole thing. Embedded values are the point. A link to a revocation server is exactly the dependency long-term validation exists to remove.

The long-term layers are written as separate document revisions, appended without disturbing the original signature’s byte range. The first signature keeps verifying. The long-term material is added around it, not into it. When the protection on the document timestamp itself ages, the archival level allows another timestamp to be layered on top. The result is a chain where each timestamp vouches for everything beneath it.

Sign The signature and its signed attributes are written (B-B).
Capture evidence Certificate chain, OCSP responses, and CRLs proving the certificate was valid at signing time are gathered.
Embed in the DSS The evidence is written into the document as embedded values, not links (B-LT).
Seal with a document timestamp A timestamp proves the embedded evidence existed and was valid at that moment (B-LTA).
Renew before it weakens Another timestamp is layered before the previous one’s protection ages, extending verifiability.

How long-term validation keeps a signature verifiable over time: the signature is created, evidence is captured while it is still obtainable, the evidence is sealed by a document timestamp, and the seal is renewed before it weakens.

What the evidence says

Evidence: Standard-backed The need is stated plainly by Spec: RFC 6960, §4.4.4 : revocation status can outlive a certificate’s validity window, and the archive cutoff mechanism gives validators historical context for deciding whether a signature was reliable at the time it was produced, even after the certificate used for validation has expired. That is the reason long-term validation exists. Revocation answers stay available only for a limited time, so you must capture them before that time ends.

The mechanism is ETSI’s. Spec: ETSI EN 319 142-2, §5.5 states the long-term behavior requires a Document Security Store carrying the validation data as values, followed by a document timestamp. Spec: ISO 32000-2, §12.8.3.3 ties it together: PAdES is CAdES CMS combined with long-term validation (§12.8.4) and the document timestamp dictionary (§12.8.5). And Spec: ETSI EN 319 142-2, §6.3.2.2 is why the timestamp goes on early: it should be applied immediately after signing so the recorded time is as close as possible to the real one.

NextPDF’s engine implements this as the B-LT and B-LTA levels: embedded revocation values in the DSS, a document timestamp sealing them, and the archival loop that renews the seal — written as appended revisions that leave the original signature’s byte range intact.

Practical example

The level you choose is the long-term decision. The API makes the requirement explicit before you commit.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// B-LT embeds validation material; B-LTA adds the renewable seal.
$level = SignatureLevel::PAdES_B_LTA;

$level->requiresDss();                // true  → certificates + revocation embedded
$level->requiresDocumentTimestamp();  // true  → a document timestamp seals the DSS

// The high-level seam produces the level end to end: it embeds the DSS
// dictionary and appends the DocTimeStamp revision in one call.
$document
    ->setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)
    ->save();

// The engine produces this only if the deployment can supply what it needs
// (a TSA, and revocation data reachable at signing time). It fails with an
// actionable error rather than embedding nothing and reporting success.

The high-level seam shown above — setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save() — is now wired end to end; earlier releases exposed the level enum but not the seam that produces it. What it writes is the structure: the DSS dictionary and the DocTimeStamp revision described by Spec: ISO 32000-2, §12.8 . That structure is not profile-conformance-tested, and the seam asserts nothing about ETSI conformance or legal validity. The B-LT and B-LTA levels require both Pro and Enterprise; on any other tier the seam fails closed rather than producing a partial result. An encrypted document also fails closed for B-LT and B-LTA; the DSS and document timestamp are not written over encrypted content, because that would write them incorrectly.

The choice cannot be retrofitted cheaply. The revocation evidence has to be captured at signing time, while the answers still exist. Deciding “we will add long-term validation later” usually means deciding “we will not have the evidence when we need it.”

Common misconception

The misconception is “long-term validation makes a signature valid forever.” It does not make anything valid. It preserves the ability to check a validity that was established at signing time. If the certificate was already revoked when the document was signed, embedding that fact does not rescue the signature. Instead it documents the failure permanently. Long-term validation is a proof-preservation mechanism, not a proof-creation one. A second misconception is believing B-LTA is “set and forget.” The archival timestamp protects with algorithms that themselves age. Without renewal, a B-LTA file eventually inherits the same fragility it was meant to escape.

Limits and boundaries

NextPDF gathers and embeds the evidence and writes the timestamps. It does not own the evidence’s truth or its renewal schedule. The revocation responses are only as good as the authority that issued them and the moment they were fetched. Connectivity to that authority at signing time is a deployment responsibility. The engine cannot invent a revocation answer it could not obtain. The archival renewal is an operational process. The engine can add another timestamp, but it cannot decide when your retention policy requires it. Whether the embedded data is later judged sufficient is a validator-and-policy question, addressed in Validating a signature properly. This page does not assert legal admissibility, which depends on jurisdiction, the signer, and the certificate.

Tier availability of long-term validation:

Long-term validation (DSS embedding and the archival timestamp loop) — edition availability
Edition	Availability
Core	Not in this edition
Pro	PAdES B-T — a trusted timestamp on the signature value — is available, but embedded validation material (DSS) is not part of B-T.
Enterprise	PAdES B-LT and B-LTA: embedded certificate and revocation values in the DSS, the sealing document timestamp, and the renewable archival loop.

PAdES baseline profiles — where B-LT and B-LTA sit in the level progression and what each adds.
Timestamps and trusted time — the document timestamp that seals the embedded evidence.
Validating a signature properly — how a validator uses the embedded material, and why “valid” alone is incomplete.
Signed-agreements workflow — the end-to-end workflow where long-term validation material is applied in practice.

Glossary

Long-term validation (LTV) — embedding the evidence needed to verify a signature so verification does not depend on external services later.
Document Security Store (DSS) — the PDF structure that holds embedded certificates and revocation data for long-term validation.
OCSP response — a signed statement of a certificate’s revocation status at a point in time (Online Certificate Status Protocol, RFC 6960).
CRL — Certificate Revocation List; a signed list of revoked certificates.
Document timestamp — an RFC 3161 timestamp applied to the whole document, proving the embedded evidence existed and was valid at that time.
Archival loop — repeatedly adding a new document timestamp before the previous one’s protection weakens, extending verifiability.