PAdES baseline mapping

At a glance

PDF Advanced Electronic Signatures (PAdES) is the profile family standardized in ETSI EN 319 142. It defines four baseline conformance levels — B-B, B-T, B-LT, and B-LTA — where each higher level adds material to the level below. This page maps those levels to what NextPDF produces. It separates the Core surface from the Pro and Enterprise editions. The mapping is behavioral: it describes what the engine emits, not internal classes.

Short version: NextPDF Core produces signature structures aligned with B-B and B-T. The B-LT and B-LTA producer path ships in the Pro and Enterprise editions. Whether a produced signature is accepted as conformant at a given level depends on the verifier and its configured trust anchors. A producer cannot assert conformance for the verifier.

Install

composer require nextpdf/core:^3

Conceptual overview

A PDF digital signature is a Cryptographic Message Syntax (CMS) SignedData structure stored in the signature dictionary’s Contents entry. The ByteRange array names the byte spans covered by the digest — ISO 32000-2 §12.8.1. CMS SignerInfo carries the signed attributes, including the content-type and message-digest attributes — RFC 5652 §5.3. The message digest over those attributes is computed by the §5.4 process. PAdES uses the CMS Advanced Electronic Signatures (CAdES) attribute model inside the PDF signature dictionary.

The four baseline levels are additive:

B-B contains the base signature with its mandatory signed attributes.
B-T adds a signature time-stamp attribute computed over the signature value. The time-stamp attribute proves the signature existed at the timestamped instant — ETSI PAdES §5.4.3. An RFC 3161 Time-Stamping Authority produces the token — RFC 3161 §2.4.1.
B-LT adds long-term validation material — certificate, Online Certificate Status Protocol (OCSP), and certificate revocation list (CRL) data — placed in the Document Security Store — ETSI PAdES §6.2.2, ISO 32000-2 §12.8.4.3, and the validation-data placement described in ETSI EN 319 142-2 §6.3.
B-LTA adds an archive document time-stamp to maintain validity over long periods — ETSI PAdES §6.2.2.

The four levels are strictly additive — each higher level keeps everything the level below it carried and adds exactly one new material layer. The transition labels show the producer edition that ships each step.

Diagram

API surface

Use the SignatureLevel enum to select a level. It defines the cases PAdES_B_B, PAdES_B_T, PAdES_B_LT, and PAdES_B_LTA. Its requiresTimestamp(), requiresDss(), requiresDocumentTimestamp(), and isAvailableInEnvironment() methods report each level’s requirements and whether the current runtime can satisfy them. In the Core distribution, isAvailableInEnvironment() returns true for B-B and B-T and false for B-LT and B-LTA. It returns false for B-LT and B-LTA because the long-term-validation producer is resolved at runtime and is not part of the open-source package. Production code should consume the SignerInterface contract rather than these internal types.

Level support matrix

Level	What it adds	Core (`nextpdf/core`)	Pro / Enterprise
B-B	Base signature with mandatory signed attributes	Produces aligned structure; tested against synthetic golden baselines	Same surface
B-T	Signature time-stamp over the signature value	Produces aligned structure when an RFC 3161 timestamp service is supplied	Same surface
B-LT	Validation data in the Document Security Store	Producer not shipped in Core; selecting B-LT without the Enterprise package fails closed	Producer shipped
B-LTA	Archive document time-stamp	Producer not shipped in Core; fails closed as above	Producer shipped

“Produces aligned structure” means NextPDF emits a signature whose structure follows the cited clauses. The project’s tests/Corpus/pades/ and tests/Golden/baselines/ artifacts exercise that structure. It does not mean an external validator certifies the output at that level. See the conformance section.

Code sample — Quick start

<?php

declare(strict_types=1);

require_once __DIR__ . '/../../vendor/autoload.php';

use NextPDF\Contracts\SignerInterface;

/**
 * Sign a byte range with any SignerInterface implementation.
 *
 * @param SignerInterface $signer    A Core or Premium signer.
 * @param string          $byteRange The PDF byte range to sign.
 *
 * @return string Hex-encoded CMS SignedData for the PDF /Contents field.
 */
function signByteRange(SignerInterface $signer, string $byteRange): string
{
    return $signer->sign($byteRange)->toHex();
}

The function depends on the SignerInterface contract, not on a concrete class. Both a Core software signer (B-B or B-T) and a Premium hardware security module (HSM) signer satisfy it. Caller code does not change when the edition changes.

Code sample — Production

<?php

declare(strict_types=1);

require_once __DIR__ . '/../../vendor/autoload.php';

use NextPDF\Security\Signature\SignatureLevel;

/**
 * Resolve the highest baseline level the current runtime can produce.
 *
 * B-B and B-T are produced by the Core distribution. B-LT and B-LTA
 * require the Enterprise long-term-validation package; without it the
 * level reports unavailable so callers fail closed rather than emit a
 * structure that does not carry the validation material the level names.
 *
 * @return SignatureLevel The highest level available in this runtime.
 */
function highestAvailableLevel(): SignatureLevel
{
    foreach ([
        SignatureLevel::PAdES_B_LTA,
        SignatureLevel::PAdES_B_LT,
        SignatureLevel::PAdES_B_T,
        SignatureLevel::PAdES_B_B,
    ] as $level) {
        if ($level->isAvailableInEnvironment()) {
            return $level;
        }
    }

    return SignatureLevel::PAdES_B_B;
}

isAvailableInEnvironment() returns true for B-B and B-T without an extra package. It returns true for B-LT and B-LTA only when the Enterprise long-term-validation package is installed. If you select an unavailable level without opting into degradation, NextPDF raises a typed unreachable-level exception whose message names the missing package. A misconfigured deployment therefore fails closed instead of silently emitting a lower level than the caller requested.

Edge cases & gotchas

A structurally B-T signature is not the same as a signature validated as B-T. Validation runs in the verifier with that verifier’s trust anchors and revocation freshness. The producer cannot assert the outcome.
PAdES B-LT and B-LTA require the NextPDF Enterprise package (nextpdf/enterprise). If it is not installed, the signer fails closed and B-LT/B-LTA are unavailable. Core provides B-B/B-T through the public NextPDF\Contracts\SignerInterface; long-term validation stays behind LtvManagerInterface. Selecting an unavailable level in Core fails closed by default. The typed exception names the missing public package, not an internal type. Graceful degradation to a lower level is opt-in, never the default.
The byte-range digest must exclude the signature value. If the digest also covers the Contents octets, verification can never succeed — ISO 32000-2 §12.8.1.
In B-T, the signature time-stamp is over the signature value, not over the document bytes. In B-LTA, the archive time-stamp is a separate document time-stamp. They are not interchangeable — ETSI PAdES §5.4.3 and §6.2.2.
ETSI EN 319 142-1 (the baseline-levels part) is not in this project’s evidence corpus. The level-structure claims here are anchored to ETSI EN 319 142-2, the pades profile document, ISO 32000-2 §12.8, and RFC 5652 / RFC 3161. Level names and additive structure are stated as implemented in v3.x. This page claims no conformance-test result or third-party attestation.

Performance

Cost grows with the level. B-B is a single signing operation and takes single-digit milliseconds for a software key. B-T adds one network round trip to the Time-Stamping Authority. B-LT adds one revocation fetch per certificate in the chain. B-LTA adds a further document time-stamp. The 1500 ms wall budget covers a single B-T signature with a remote Time-Stamping Authority (TSA) on a warm connection. B-LT or B-LTA against a slow revocation endpoint exceeds it and belongs outside the request path. The reproducibility profile is structural, not bitwise. A time-stamp embeds the signing instant, so two runs differ in the time-stamp bytes while the document structure stays identical.

Security notes

The level a signature claims and the level at which it is validated are different facts. This page describes only the producer surface. Long-term validation depends on validation data collected at signing time and on the verifier trusting the same anchors later. The producer cannot guarantee either fact. Time-stamp trust reduces to trust in the Time-Stamping Authority, which the deployment pins through an injectable provider. This page is marked export_control_class: legal-review-required because it concerns cryptographic signature profiles. All normative sources are paraphrased, and none are reproduced, per citation hygiene.

Conformance

Claim	Standard	Clause	Evidence
The signature value is stored DER-encoded as CMS SignedData or a TimeStampToken in the signature dictionary `Contents` entry.	ISO 32000-2	§12.8.1
The digest is computed over the `ByteRange` spans and excludes the signature value.	ISO 32000-2	§12.8.1
The signature time-stamp attribute is computed over the signature value (B-T).	ETSI PAdES (EN 319 142)	§5.4.3
Long-term validation material is carried in the Document Security Store (B-LT).	ETSI PAdES (EN 319 142) / ISO 32000-2	§6.2.2 / §12.8.4.3	,
Validation data is placed in the DSS and VRI dictionaries.	ETSI EN 319 142-2	§6.3	,
An archive document time-stamp maintains validity over long periods (B-LTA).	ETSI PAdES (EN 319 142)	§6.2.2
SignerInfo carries content-type and message-digest signed attributes.	RFC 5652	§5.3
The message digest is computed over the DER-encoded signed attributes (§5.4 process).	RFC 5652	§5.4
The time-stamp is requested from an RFC 3161 TSA and returns a TSTInfo structure.	RFC 3161	§2.4.1

All clauses are paraphrased. NextPDF does not reproduce normative text. Consult the published standards for the authoritative wording. ETSI EN 319 142-1 is not in the evidence corpus. Structural claims about the baseline levels are anchored to the sources above and are stated as implemented in v3.x.

Commercial context

Core produces B-B and B-T signature structures. The B-LT and B-LTA producer path, HSM and PKCS#11 key custody, and the FIPS 140-3 crypto-policy profile ship in the Pro and Enterprise editions. Core resolves the long-term-validation producer at runtime, so the open-source engine carries no commercial dependency. The SignerInterface API does not change on upgrade.