Signature: PAdES B-LT / B-LTA, DSS, document timestamps

At a glance

NextPDF Enterprise adds a long-term producer above the Core Cryptographic Message Syntax (CMS) signature: a Document Security Store (DSS), per-signature validation-related information (VRI), and document timestamps. These structures raise a PDF Advanced Electronic Signatures (PAdES) baseline signature from B-B to B-LT and then to B-LTA. This page describes behavior. It states what the producer writes, what it does not decide, and where the Pro boundary begins.

Install

composer require nextpdf/enterprise

nextpdf/enterprise depends on nextpdf/core and nextpdf/pro. Resolve the package with your NextPDF license credentials on Private Packagist.

Conceptual overview

A PAdES baseline signature has four levels. Each level adds material to the previous one. B-B is a CMS signature with signed attributes. B-T adds a trusted RFC 3161 timestamp on the signature value. B-LT adds a DSS that carries the certificates, Online Certificate Status Protocol (OCSP) responses, and certificate revocation lists (CRLs) a verifier needs after the signing certificate expires. B-LTA adds a document timestamp over the whole document state, including the DSS, so the validation material stays time-anchored.

Core builds the CMS SignedData and stores it DER-encoded in the signature dictionary Contents entry — ISO 32000-2 §12.8.1. Long-term validation uses two dictionary types: a document security store and a document timestamp dictionary — ISO 32000-2 §12.8. The Enterprise producer writes the DSS that holds the certificate, OCSP, and CRL material — ISO 32000-2 §12.8.4.3 — and, for B-LTA, the document timestamp dictionary — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 describes the same long-term structure: DSS entries plus document time-stamps for long-term signatures — §5.5 — supported by the signature handler — §6.3.3.3.

The producer collects revocation material for each certificate in the chain. It asks an OCSP responder first; an OCSP response reports good, revoked, or unknown — RFC 6960 §2.2 — and the thisUpdate and nextUpdate fields bound the status freshness — RFC 6960 §4.2. If OCSP is unavailable, it falls back to a CRL. The producer walks the chain from the signer toward a trust anchor following the path-validation inputs — RFC 5280 §6.1.

The B-LTA document timestamp is an RFC 3161 exchange with a Time-Stamping Authority (TSA). The request returns a Time Stamp Information (TSTInfo) value — RFC 3161 §2.4.1 — whose genTime is the Coordinated Universal Time (UTC) instant the token was created — RFC 3161 §2.4.2. The token is embedded in a /DocTimeStamp dictionary with /SubFilter /ETSI.RFC3161 that covers the whole file.

The verifier decides whether a produced signature verifies, using its configured trust anchors and revocation policy. The producer embeds material; it does not assert a trusted outcome. This boundary is restated where it matters below.

The order is load-bearing: the DSS must be written before the B-LTA document timestamp, because the timestamp must cover the document state that already contains the validation material. The flow below shows that producer sequence.

Diagram

API surface

You consume the Enterprise long-term producer through the Core contract. Production code depends on the contract, not on the concrete Enterprise implementation type.

Type	Kind	Role	Stability	Since
`SignerInterface`	interface (`NextPDF\Contracts`)	Core signing contract for callers	stable	1.0.0
`SignatureLevel`	enum (`NextPDF\Security\Signature`)	PAdES level selector: B-B, B-T, B-LT, B-LTA	stable	1.0.0
`LtvManagerInterface`	interface (`NextPDF\Contracts`)	Long-term-validation producer contract resolved at runtime	stable	1.0.0
`TsaClientInterface`	interface	RFC 3161 TSA client the producer calls for document timestamps	stable	1.0.0

SignatureLevel::requiresDss() is true for B-LT and B-LTA; SignatureLevel::requiresDocumentTimestamp() is true only for B-LTA. Core SignatureLevel::isAvailableInEnvironment() returns false for B-LT and B-LTA when the Enterprise long-term producer is not installed; the Core orchestrator then fails closed. The concrete Enterprise producer classes are internal and are not part of the public API; depend on LtvManagerInterface and the enum.

Code sample — Quick start

<?php

declare(strict_types=1);

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

use NextPDF\Security\Signature\SignatureLevel;

/**
 * Select the PAdES level for a long-term signature.
 *
 * B-LT embeds a DSS. B-LTA also adds a document timestamp.
 * Both require the nextpdf/enterprise long-term producer at runtime.
 *
 * @return SignatureLevel The requested PAdES baseline level.
 */
function longTermLevel(): SignatureLevel
{
    return SignatureLevel::PAdES_B_LTA;
}

The signing configuration carries the level. The Core orchestrator resolves the long-term producer through LtvManagerInterface at runtime, so application code does not reference the Enterprise type.

Code sample — Production

<?php

declare(strict_types=1);

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

use NextPDF\Contracts\LtvManagerInterface;
use NextPDF\Contracts\SignerInterface;
use NextPDF\Exception\NextPdfException;
use Psr\Log\LoggerInterface;

final readonly class LongTermSigner
{
    public function __construct(
        private SignerInterface $signer,
        private LtvManagerInterface $ltv,
        private LoggerInterface $logger,
    ) {}

    /**
     * Sign, then embed the DSS and the B-LTA document timestamp.
     *
     * The order matters: the DSS is written first, then the document
     * timestamp is taken over the document state that already includes it.
     *
     * @param string $byteRange The PDF byte range to sign.
     *
     * @throws NextPdfException When revocation material is missing under the
     *                          fail-closed enforcement default, or when no TSA
     *                          is configured for B-LTA.
     */
    public function sign(string $byteRange): string
    {
        try {
            $contents = $this->signer->sign($byteRange)->toHex();
            // The orchestrator drives DSS collection and the document
            // timestamp through the resolved LtvManagerInterface; revocation
            // freshness and TSA reachability are operational inputs.
            return $contents;
        } catch (NextPdfException $e) {
            $this->logger->error('long-term signing failed', ['reason' => $e->getMessage()]);
            throw $e;
        }
    }
}

The DSS must be written before the document timestamp. The B-LTA timestamp covers the full file, including the DSS, which time-anchors the validation material itself.

Edge cases & gotchas

Missing revocation material fails closed by default. When no enforcement mode is set, the producer treats a missing OCSP response and a missing CRL for any non-root certificate as an error, not a warning. This prevents a document that claims a long-term level from being written with no revocation material in the DSS. The permissive workflow is opt-in and warn-only.
B-LTA needs a TSA. A document timestamp is an RFC 3161 round trip. With no TSA client configured, the B-LTA step raises an error rather than silently producing B-LT.
Order is load-bearing. Add the document timestamp only after the DSS is written. A timestamp taken before the DSS does not cover the validation material.
Air-gapped runs. Under a strict-offline network policy, the producer makes no OCSP/CRL fetch and no TSA request; it uses only material already embedded in the DSS. B-LTA, which requires a fresh TSA token, is not reachable strict-offline.
VRI is opt-in. Per-signature VRI is not written by default. Some validators display long-term status better when VRI is present; enable it when a target verifier needs it.

Performance

DSS assembly cost scales with chain length and the number of revocation responses fetched. Each OCSP or CRL fetch is one network round trip; pre-collected or cached material removes those round trips. A B-LTA run adds one TSA round trip for the document timestamp. The 1500 ms wall budget covers a single long-term signature with warm OCSP/CRL and TSA connections; cold or slow responders dominate wall time. The reproducibility profile is structural: timestamps embed the signing and stamping instants, so two runs differ in those bytes while the document structure is identical.

Security notes

Trust is the verifier’s decision. The producer embeds certificates, OCSP, and CRLs. Whether the signature validates depends on the verifier, its trust anchors, and its revocation-freshness policy. NextPDF ships no built-in trust list.
Revocation freshness is time-bounded. OCSP thisUpdate/nextUpdate and CRL validity windows bound how long embedded material remains useful. The archival loop re-stamps before the timestamp certificate expires; you are responsible for operating it on schedule.
Fail-closed default. The strict revocation-enforcement default prevents a long-term claim from being made without the material that backs it.
See the Enterprise threat model section and Archive: DSS, VRI, LTV health.

Data Residency & PII Mitigations

OCSP and CRL fetching contacts the responders named in each certificate; those endpoints and the TSA see request metadata. In a data-residency-constrained deployment, pre-collect revocation material and run under the strict-offline policy so no responder or TSA is contacted at signing time. Certificates carry subject identity. The producer embeds the certificates required for validation and does not add identity beyond the chain; it does not strip subject fields from a certificate you supply.

Safe Telemetry & Log Scrubbing

Producer diagnostics report level, chain position, and the missing-material condition. They do not log private keys or full certificate bodies. When you wire a PSR-3 logger, keep diagnostic logs at a non-production verbosity for signing flows and scrub responder URLs if they reveal internal infrastructure. Treat embedded OCSP/CRL bytes as document content, not log content.

FIPS-mode behavior

The Federal Information Processing Standards (FIPS) 140-3 crypto-policy profile is an Enterprise capability documented with the security module. The long-term producer adds no cryptographic primitive of its own beyond the SHA-256 digest used for the document timestamp and the RFC 3161 exchange; the signing primitive is the Core signer’s. When the FIPS profile is active, the same DSS and document-timestamp structures are produced; the constraint applies to the underlying signing and digest algorithms, not to the DSS layout.

Threat model

Asset	Adversary	Risk	Mitigation
DSS revocation material	Stale-material acceptance	A verifier trusts expired revocation data	OCSP/CRL freshness fields bound validity; the archival loop re-stamps before expiry
B-LTA document timestamp	TSA compromise or unreachable TSA	No trustworthy time anchor	Caller-chosen TSA; B-LTA fails closed when no TSA is configured
Long-term claim	Silent missing-material	A “long-term” PDF with no revocation data	Fail-closed enforcement default raises an error instead of a warning
Signature verification	Misconfigured verifier trust	Apparent validity that the verifier should not assert	Producer states it embeds material only; the trust decision is the verifier’s

Conformance

Claim	Standard	Clause	reference_id
The signature value (or timestamp token) is stored DER-encoded in `/Contents`.	ISO 32000-2	§12.8.1
Long-term validation uses a DSS and a document timestamp dictionary.	ISO 32000-2	§12.8
The DSS holds certificates, OCSP responses, and CRLs.	ISO 32000-2	§12.8.4.3
The document timestamp uses a document timestamp dictionary.	ISO 32000-2	§12.8.5
DSS entries and document time-stamps support long-term signatures.	ETSI EN 319 142-2	§5.5
The signature handler supports DSS entries and document time-stamps.	ETSI EN 319 142-2	§6.3.3.3
A timestamp token carries a UTC genTime that is the instant it was created.	RFC 3161	§2.4.2
OCSP reports good, revoked, or unknown, bounded by thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2	,

All clauses are paraphrased. NextPDF does not reproduce normative text; consult the published standards for the authoritative wording. NextPDF makes no PAdES certification claim. The structures described here are aligned with the B-LT and B-LTA levels as defined in ETSI EN 319 142; no conformance-test result or third-party attestation is claimed. The ETSI EN 319 142-1 baseline-levels part is outside the cited evidence set, so this page states the produced structure and the Pro/Enterprise boundary, not a certified conformance level. The cited ETSI evidence is EN 319 142-2; the ISO and RFC anchors carry the long-term and timestamp claims, as they do in the Core signing reference.

Edition gate

NextPDF Core produces the B-B and B-T PAdES baseline levels: Core ships the software CMS signer plus the RFC 3161 timestamp path, so a B-T (timestamped) signature is a Core capability and does not require Enterprise. NextPDF Pro also produces B-B and B-T: Pro composes the Core RFC 3161 stack to add the signature-time-stamp unsigned attribute on the signature value (PadesBtTimestamper, fixture-verified). The B-LT and B-LTA levels — the DSS, VRI, and document-timestamp producer — are an Enterprise capability and are not produced by Core or Pro. This matches the published tier table on the Pro security page: B-B and B-T are produced by Core and Pro, and B-LT and B-LTA by Enterprise only. The B-T producer is structural: it composes the RFC 3161 signature-time-stamp per the cited RFC 3161 / RFC 5652 / ETSI EN 319 122-1 evidence; it is not a certified ETSI EN 319 142-1 conformance or eIDAS-qualified claim. In a Pro-only deployment, requesting B-LT or B-LTA fails closed with a message that names the missing Enterprise component, because SignatureLevel::isAvailableInEnvironment() returns false when the Enterprise long-term producer is absent.

PAdES level	Adds	Producer edition
B-B	CMS signature with signed attributes	Core, Pro, Enterprise
B-T	RFC 3161 signature-time-stamp on the signature value (structural; not eIDAS-qualified)	Core, Pro, Enterprise
B-LT	Document Security Store with validation material	Enterprise (`nextpdf/enterprise`) only
B-LTA	Document timestamps for archival validity	Enterprise (`nextpdf/enterprise`) only

This is the canonical level→tier matrix: B-B is the baseline produced by every edition; B-T (timestamped) is also produced by Core and Pro (Pro composes the Core RFC 3161 stack); B-LT and B-LTA are Enterprise-only. The B-T producer is structural; it is not a certified ETSI EN 319 142-1 conformance or eIDAS-qualified claim.

License feature flag

The long-term producer is part of the Enterprise edition (license_feature_flag: enterprise). It resolves at runtime through the Core contract; the public API does not change when you upgrade from Pro to Enterprise.

Behavior contract

Core and Pro both produce B-B and B-T (B-T adds the RFC 3161 signature-time-stamp; Pro composes the Core RFC 3161 stack). B-LT and B-LTA are an Enterprise boundary; requesting them without nextpdf/enterprise fails closed with a named error.
The producer writes a DSS (B-LT) and a document timestamp over the DSS (B-LTA). It embeds validation material; it does not assert a trusted verification outcome.
The fail-closed revocation-enforcement default raises an error when revocation material is missing for a non-root certificate, unless the caller opts into the permissive workflow.
B-LTA requires a configured TSA; with none, the B-LTA step raises an error rather than degrading to B-LT.

NDA scan status

This public page describes externally observable producer behavior only. It contains no internal namespace paths, no internal class or trait names, no runbook filenames, and no internal ticket prefixes. The concrete Enterprise long-term-producer types are referenced only through the public Core contract (LtvManagerInterface, SignatureLevel). Detailed DSS-assembly and archival-loop internals are in the gated deep reference under a nondisclosure agreement (NDA).

Core fallback

In a Core-only deployment, the software signer produces PAdES B-B and B-T with a local key or a key supplied through the Core signing-strategy contract. Core ships the RFC 3161 timestamp path, so B-T is reachable without any premium package. Core has no DSS, VRI, or document-timestamp producer; requesting B-LT or B-LTA fails closed with a named error. See Security / Signing (Core).

Pro fallback

In a Pro-only deployment, the supported signing path is the Pro B-B baseline and the Pro B-T level (Pro composes the Core RFC 3161 stack to add the signature-time-stamp unsigned attribute), plus its remote and cloud key management service (KMS) signing strategies. Pro produces no DSS, VRI, or document timestamp. A configuration that requests B-LT or B-LTA in a Pro-only deployment fails closed with a message that names the missing Enterprise component. See Pro security for the Pro signing surface.

Enterprise boundary note

The DSS, VRI, and document-timestamp producer is described at the behavior level only. Internal DSS-assembly ordering logic, per-signature VRI keying internals, and archival-loop scheduling internals are out of scope for the public surface and are not reproduced here.

Deployment boundary

NextPDF Enterprise embeds validation material; it integrates with caller-supplied OCSP/CRL responders and an RFC 3161 TSA. It does not itself operate, host, or guarantee the availability of those responders or the TSA. Long-term validity depends on the responders, the TSA, the archival-loop schedule, and the operator — not on NextPDF Enterprise alone. The operator is responsible for TSA selection and reachability, revocation-responder access or pre-collected material, the network policy, and running the archival loop before each timestamp certificate expires.

Legal-compliance boundary

This page is marked export_control_class: legal-review-required. It concerns cryptographic signing and long-term validation. Legal sign-off is required before the publish flag is set. Alignment with the B-LT and B-LTA structures defined in ETSI EN 319 142 is a structural statement, not a legal opinion and not a certification. NextPDF makes no PAdES certification claim. Consult your compliance and legal advisers for your regulatory obligations.