PAdES baseline profiles

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

At a glance

PAdES defines four baseline levels — B-B, B-T, B-LT, B-LTA — that build on each other. Each adds one specific kind of evidence. This page explains the progression and helps you pick the lowest level that still meets the obligation, instead of the highest level you happen to know by name.

Why this matters

People reach for “B-LTA” because it sounds the most thorough, or for “B-B” because it is the least work. Both are guesses. A question decides the level you need, not a preference: how long must this signature stay verifiable, and by whom? Choose too low and a signature that was valid on signing day becomes unverifiable when a certificate expires. Choose too high and you take on a timestamp authority and validation-material infrastructure you did not need, plus an archival obligation you must keep feeding. The team that cannot change the level later pays the cost of the wrong one.

The short version

The four levels are cumulative. Each is the previous one plus one addition.
B-B — the signature with its mandatory signed attributes. Proves who and what.
B-T — B-B plus a trusted timestamp on the signature. Proves when, independently of the signer’s clock.
B-LT — B-T plus embedded validation material (certificates and revocation data). The document carries its own proof that the certificate was good at signing time.
B-LTA — B-LT plus a document timestamp, repeated over time. Keeps the whole thing verifiable across decades and algorithm changes.
Pick the level by the obligation’s lifetime, not by what looks safest.

How NextPDF approaches it

NextPDF models the level as an explicit, ordered choice, and refuses to pretend. You ask for a level. The engine produces exactly that level or fails with an actionable error. It does not quietly sign at a lower level and let a compliance record claim a higher one. This design exists precisely to prevent a silent downgrade of a B-LTA request to B-T when the infrastructure was missing. Each level’s requirements are encoded as predicates: whether a timestamp is required, whether embedded validation material is required, whether a document timestamp is required. The engine walks those predicates and either satisfies them or stops.

The progression below is the same one the engine enforces and the standard defines.

Level	Adds over the previous level	The question it answers	Needs from your deployment
B-B	Signed attributes: content-type, message-digest, signing-time, signing-certificate-v2	Who signed, and what exact bytes?	A signing key and certificate
B-T	A trusted timestamp over the signature value	When was it signed, provably?	A Time-Stamp Authority (TSA)
B-LT	Embedded certificates + revocation data (a DSS)	Was the certificate valid at signing — provable later?	TSA + access to revocation data at sign time
B-LTA	A document timestamp, renewable over time	Will this still be verifiable in decades?	TSA + an archival process that re-timestamps

The jump that matters most is B-T to B-LT. B-T proves when. B-LT makes the document self-contained for trust: it stops depending on a certificate authority still being reachable and answering questions years from now.

Step 1 of 4: ISO 32000-2 §12.8 — signatures, LTV, document timestamp
Step 2 of 4: ETSI EN 319 142-1 PAdES baseline levels B-B…B-LTA
Step 3 of 4: RFC 3161 Timestamp token (introduced at B-T)
Step 4 of 4: RFC 6960 OCSP revocation evidence (embedded at B-LT)

The standards behind the PAdES progression: ISO 32000-2 defines how signatures and validation material sit in the PDF; ETSI EN 319 142-1 defines the baseline levels; RFC 3161 defines the timestamp that B-T introduces; RFC 6960 defines the revocation evidence B-LT embeds.

What the evidence says

Evidence: Standard-backed The level definitions are ETSI’s. Spec: ETSI EN 319 142-1 defines the PAdES baseline levels; Spec: ETSI EN 319 142-2, §5.3 shows the signature-time-stamp attribute as the optional element whose presence is what separates a timestamped level from B-B, and Spec: ETSI EN 319 142-2, §6.3.2.2 states a trusted timestamp should be applied immediately after the signature is created, so the recorded time is as close as possible to the real signing time. Spec: ETSI EN 319 142-2, §5.5 states that the long-term behavior requires both a Document Security Store and document timestamps — the B-LT and B-LTA additions.

The container side is Spec: ISO 32000-2, §12.8.3.3 : PAdES signatures are CAdES CMS profiles combined with long-term validation (§12.8.4) and the document timestamp dictionary (§12.8.5), exactly as ETSI EN 319 142-1 describes. The reason B-LT matters is captured by Spec: RFC 6960, §4.4.4 : archived revocation evidence helps a validator reason about the signature’s reliability at production time, even after the certificate used for validation has expired. That is the point of embedding it.

NextPDF’s engine encodes each level as a requirement predicate and produces the requested level or fails — it does not advertise a level it did not build.

Practical example

The API mirrors the progression: you name the level, and the engine treats it as a contract.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// The level is an explicit, ordered choice — not a flag you hope is honoured.
$level = SignatureLevel::PAdES_B_T;

// The level itself tells you what it requires, before you sign:
$level->requiresTimestamp();          // B-T and above → true
$level->requiresDss();                // B-LT and above → true
$level->requiresDocumentTimestamp();  // B-LTA only     → true

// Ask for B-LTA only if the deployment can actually fulfil it.
// The engine produces exactly the requested level or fails with an
// actionable error — it never silently signs lower and reports higher.

If you request B-LTA and the deployment cannot supply what B-LTA needs, the default behavior is to fail and tell you the highest level it could have reached — not to quietly hand back a B-T file labeled B-LTA.

Common misconception

The trap is “B-LTA is just the best one, always pick it.” B-LTA is not better in the abstract; it is more, and more carries obligations. It requires a timestamp authority, revocation material gathered at signing time, and an ongoing archival process that re-timestamps the document before its protecting algorithms or timestamp certificates weaken. A B-LTA file that nobody re-timestamps is not future-proof — it is a B-LT file with extra ceremony. Conversely, B-B for a contract that must survive a decade is not “lightweight”; it is a signature that will fail validation the day the certificate expires. The right level is the one the obligation requires, no higher and no lower.

Limits and boundaries

NextPDF produces the requested PAdES level; it does not supply the parties that level depends on. A timestamp authority, the certificate chain, the trust anchors, and the connectivity to fetch revocation data at signing time are deployment responsibilities. The engine implements the structure and enforces the level contract; it cannot make a TSA trustworthy or a certificate valid. The produced structure carries the elements that level requires, verified against the engine’s own tests and the cited clauses. It is not a third-party conformance certification, and this page does not assert eIDAS legal effect, which depends on the certificate, the signer, and the jurisdiction. Whether the signing time is independently trusted is covered in Timestamps and trusted time; how the long-term evidence keeps a signature alive is covered in Long-term validation.

A few boundaries to set expectations precisely:

B-LT and B-LTA emit the long-term-validation structure, not a conformance verdict. What the engine writes is a Document Security Store dictionary plus a document-timestamp revision — a signature dictionary with Type = DocTimeStamp per Spec: ISO 32000-2, §12.8 . That structure is not advertised here as profile-conformance-tested; the ETSI EN 319 142-1 profile checks are release-gated on the Pro and Enterprise CI lane, so this page does not claim ETSI EN 319 142-1 conformance for the produced file.
Encrypted documents fail-closed for B-LT and B-LTA. A request for a long-term level on an encrypted document stops with an actionable error rather than writing a partial long-term revision.

Tier availability of each level — all four reached through the same high-level seam, setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save():

PAdES baseline level — edition availability
Edition	Availability
Core	PAdES B-B — the signed-attribute baseline; the Core seam.
Pro	Adds PAdES B-T — a trusted timestamp on the signature value, driven by a `TsaClient`.
Enterprise	Adds PAdES B-LT and B-LTA — embedded validation material (DSS) and the renewable document-timestamp archival loop. These run through the same high-level seam, but only when both the Pro and Enterprise packages are installed; with either missing, the call fail-closes rather than write a partial long-term revision.

How signatures sit in a PDF — the byte-range and dictionary foundation every level builds on.
Long-term validation — what B-LT and B-LTA actually embed, and why a valid signature can fail later without it.
Timestamps and trusted time — the RFC 3161 timestamp that B-T introduces and B-LTA renews.
Signed-agreements workflow — the practical workflow that puts a chosen PAdES baseline level to work.

Glossary

PAdES — PDF Advanced Electronic Signatures; the ETSI EN 319 142 series profiling CMS signatures for PDF.
Baseline level — one of B-B, B-T, B-LT, B-LTA; a defined, cumulative set of required signature elements.
B-B — the baseline signature with its mandatory signed attributes.
B-T — B-B plus a trusted timestamp on the signature value.
B-LT — B-T plus embedded long-term validation material (a DSS).
B-LTA — B-LT plus a renewable document timestamp for archival validity.
DSS — Document Security Store; the PDF structure holding embedded certificates and revocation data.
TSA — Time-Stamp Authority; a trusted service that issues RFC 3161 timestamp tokens.