Signature — Deep Reference

Gated content notice. This page is part of the gated reference surface. Distribution is restricted by NDA. Do not mirror this page to public channels.

At a glance

This is the deep reference for the NextPDF Enterprise long-term producer: how a B-LT or B-LTA signature is assembled, how revocation material is collected and enforced, how the document timestamp anchors the document, and how the Pro boundary is enforced. It is behavior-level and contract-level. Concrete Enterprise implementation types are intentionally not named here; the page references the public package and the Core contract surface only.

Edition gate

Requires NextPDF Enterprise (nextpdf/enterprise) for the long-term producer. The canonical level→tier matrix: B-B is the baseline produced by Core, Pro, and Enterprise; B-T (timestamped) is produced by Core and Enterprise but not Pro — Core ships the RFC 3161 timestamp path, so B-T does not require a premium package, while Pro produces B-B only; B-LT and B-LTA (DSS, VRI, document timestamp) are produced by Enterprise only. In a Pro-only deployment, requesting B-LT or B-LTA fails closed: the Core SignatureLevel::isAvailableInEnvironment returns false when the Enterprise long-term producer is absent, and the Core orchestrator raises a named error rather than degrading the level silently.

PAdES level	Adds	Producer edition
B-B	CMS signature with signed attributes	Core, Pro, Enterprise
B-T	Trusted RFC 3161 timestamp on the signature value	Core, Enterprise (not Pro)
B-LT	Document Security Store with validation material	Enterprise only
B-LTA	Document timestamp over the DSS (archival loop)	Enterprise only

License feature flag

license_feature_flag: enterprise. The producer resolves at runtime through the Core long-term contract; the public API does not change on upgrade from Pro to Enterprise.

Conceptual model

A B-LT signature is a B-T signature plus a Document Security Store. The DSS is a Catalog-level dictionary holding the certificate, OCSP-response, and CRL streams a verifier needs once the signing certificate has expired — ISO 32000-2 §12.8.4.3. Long-term validation uses two dictionary types — a DSS and a document timestamp dictionary — ISO 32000-2 §12.8. The CMS signature itself is stored DER-encoded in /Contents — ISO 32000-2 §12.8.1.

A B-LTA signature adds a document timestamp over the entire document state, including the DSS, written through the document timestamp dictionary — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 describes the same long-term composition — §5.5 — and the handler support — §6.3.3.3.

Producer workflow

Build the chain. The signer certificate plus any caller-supplied intermediates form the chain, signer first, toward the trust anchor — RFC 5280 §6.1.
Collect revocation material. For each non-root certificate, the producer queries OCSP first. An OCSP response reports good, revoked, or unknown — RFC 6960 §2.2 — and is time-bounded by thisUpdate/nextUpdate — RFC 6960 §4.2. If OCSP is unavailable it falls back to a CRL, with delta-CRL support; a base CRL and an optional delta are added as separate DSS entries.
Write the DSS. Certificates, OCSP responses, and CRLs are written as individual PDF stream objects; duplicates are de-duplicated by content hash. The DSS dictionary references them through /Certs, /OCSPs, /CRLs.
Per-signature VRI (opt-in). A VRI entry, keyed by the uppercase hash of the signature’s /Contents value, indexes the specific certs/OCSP/CRLs for that signature, with an optional validation-time entry. VRI is off by default: ETSI EN 319 142-1 V1.2.1 §5.4 recommends against VRI in the DSS for new documents; some validators still display long-term status better with it, so it is caller-enableable.
Document timestamp (B-LTA). After the DSS is written, a /DocTimeStamp dictionary with /SubFilter /ETSI.RFC3161 is appended with ByteRange and /Contents placeholders. After the full file is assembled, the producer computes the SHA-256 digest over the ByteRange, requests an RFC 3161 token — §2.4.1 — and embeds the DER token; genTime is the UTC token-creation instant — §2.4.2.

Revocation enforcement

The producer resolves an enforcement mode with this precedence: an explicit structured enforcement mode wins; otherwise an explicit (deprecated) boolean maps to strict or permissive; otherwise the default is strict (fail-closed).

Under strict enforcement, a missing OCSP response and a missing CRL for any non-root certificate raises an error rather than emitting only a warning. The fail-closed default exists so a “B-LT” PDF cannot be produced with no revocation material in the DSS while still advertising the long-term level. The permissive (warn-only) workflow must be opted into explicitly. Under a strict-offline network policy, no OCSP/CRL fetch occurs; only DSS-embedded material is used, and the missing-material condition is handled by the same enforcement rule.

Archival loop

The B-LTA document timestamp is anchored by a TSA certificate that itself expires. The archival loop, run before that expiry, collects fresh revocation material for the TSA certificate chain, rewrites the DSS, optionally adds a VRI entry keyed by the TSA certificate hash, and adds a new document timestamp over the updated state. Each new timestamp covers the previous ones. Running the loop on schedule is an operational obligation; the producer raises an error if the loop is requested with no TSA configured or under strict-offline policy. The full archival surface is documented on the Archive deep reference.

API surface (public contract only)

Type	Kind	Role	Stability	Since
`SignerInterface`	interface (`NextPDF\Contracts`)	The Core signing contract	stable	1.0.0
`LtvManagerInterface`	interface (`NextPDF\Contracts`)	The long-term producer + archival-loop contract resolved at runtime	stable	1.0.0
`TsaClientInterface`	interface	RFC 3161 TSA client the producer calls	stable	1.0.0
`SignatureLevel`	enum (`NextPDF\Security\Signature`)	B-B, B-T, B-LT, B-LTA selector and availability probe	stable	1.0.0

SignatureLevel::requiresDss → true for B-LT, B-LTA. requiresDocumentTimestamp → true only for B-LTA. requiresTimestamp → true for B-T, B-LT, B-LTA. Production code depends on these contracts; the concrete Enterprise implementation classes are internal and are not part of the public API.

Conformance

Claim	Standard	Clause
Signature/timestamp stored DER-encoded in `/Contents`.	ISO 32000-2	§12.8.1
LTV uses a DSS and a document timestamp dictionary.	ISO 32000-2	§12.8
DSS is the dictionary that is the value of the DSS key in the document catalog; holds Certs, OCSPs, CRLs.	ISO 32000-2	§12.8.4.3
Document timestamp dictionary structure.	ISO 32000-2	§12.8.5
DSS + document time-stamps for long-term signatures.	ETSI EN 319 142-2	§5.5
Handler supports DSS + document time-stamps.	ETSI EN 319 142-2	§6.3.3.3
RFC 3161 request returns TSTInfo; genTime is UTC creation instant.	RFC 3161	§2.4.1, §2.4.2
OCSP good/revoked/unknown bounded by thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2
Path validation inputs to a trust anchor.	RFC 5280	§6.1

All clauses are paraphrased. NextPDF does not reproduce normative text. NextPDF makes no PAdES certification claim: the producer writes structures aligned with the B-LT and B-LTA levels 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 the cited ETSI anchor is EN 319 142-2 and the ISO/RFC anchors carry the long-term and timestamp claims — the same disclosure posture as the Core signing reference. Whether a produced signature verifies is the verifier’s decision against its trust anchors and revocation-freshness policy; the producer embeds material and does not assert a trusted outcome.

Edge cases & FIPS-mode behavior

Edge cases

The DSS must be written before the document timestamp; a timestamp written before the DSS does not cover the validation material.
Strict enforcement (the default) raises an error when revocation material is missing for a non-root certificate. Permissive is opt-in.
B-LTA with no TSA configured raises an error rather than producing B-LT.
Strict-offline policy: no OCSP/CRL/TSA network access; B-LTA is not reachable strict-offline.
The document-timestamp token has a bounded reserved space; a token exceeding it raises an error rather than truncating.

FIPS-mode behavior

The FIPS 140-3 crypto-policy profile is an Enterprise capability documented with the security module. The long-term producer adds only the SHA-256 digest used for the document timestamp and the RFC 3161 exchange; the signing primitive is the Core signer’s. Under the FIPS profile the same DSS, VRI, and document-timestamp structures are produced; the constraint applies to the signing and digest algorithms, not to the DSS layout. Hardware key custody through PKCS#11 is documented with the security module and is out of scope for this page.

Behavior contract

Core produces B-B and B-T (B-T adds the RFC 3161 timestamp on the signature value). Pro produces B-B only and applies no timestamp. B-LT and B-LTA are produced by Enterprise only.
The producer writes the 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.

Core fallback

In a Core-only deployment, the software signer produces PAdES B-B and B-T through SignerInterface; Core ships the RFC 3161 timestamp path so B-T needs no premium package. Core has no DSS, VRI, or document-timestamp producer; a B-LT or B-LTA request fails closed via SignatureLevel::isAvailableInEnvironment returning false.

Pro fallback

In a Pro-only deployment, the signing path is the Pro B-B baseline plus remote and cloud-KMS signing strategies. Pro applies no RFC 3161 timestamp and produces no DSS or document timestamp. RemoteSigningConfig carries the Core SignatureLevel enum, but a level above B-B is a forward-declared value Pro does not act on; the timestamped or long-term producer resolves at runtime through the Core contract and ships in nextpdf/enterprise.

Enterprise boundary note

This page references the public package and the Core contract surface only. Concrete Enterprise long-term-producer implementation types are intentionally not named. The internal DSS-assembly ordering, the VRI-keying internals, and the archival-loop scheduling internals are out of scope and 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 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 owns TSA selection and reachability, revocation-responder access or pre-collected material, the network policy, and running the archival loop before each timestamp certificate expires.

NDA scan status

This gated page references public API class names and the Core contract surface only. It contains no internal namespace paths, no internal trait names, no internal DSS-assembly tables, no runbook filenames, and no internal ticket prefixes. Attested in the co-located NDA checklist.

Legal-compliance boundary

This module is flagged export_control_class: legal-review-required. Legal sign-off is required before publish: true; see LEGAL_SIGNOFF_PACKET.md. 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. Whether a produced signature verifies is the verifier’s decision against its trust anchors and revocation-freshness policy.