Enterprise edition

Archive — Deep Reference

At a glance

This is the deep reference for the NextPDF Enterprise archival surface: how the DSS and VRI are structured, what the LTV health check inspects, and how the document-timestamp archival loop extends validity over time. 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.

Availability & licensing

This capability ships in NextPDF Enterprise (nextpdf/enterprise) and activates with an Enterprise-tier license envelope. A deployment without that entitlement does not load the capability’s classes. Compare editions and get a license.

The canonical level→tier matrix: B-B is the baseline produced by Core, Pro, and Enterprise; B-T (timestamped) is produced by Core, Pro, and Enterprise — Core ships the RFC 3161 timestamp path, so B-T does not require a premium package; Pro writes no DSS or document timestamp; B-LT and B-LTA are produced by Enterprise only. In a Pro-only deployment, requesting a long-term level fails closed with a message that names the missing Enterprise component.

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, Pro, Enterprise
B-LT	Document Security Store with validation material	Enterprise only
B-LTA	Document timestamp over the DSS (archival loop)	Enterprise only

DSS and VRI structure

The DSS is a Catalog-level dictionary that carries the validation material a verifier needs after a signing certificate expires — ISO 32000-2 §12.8.4.3. It exposes /Certs, /OCSPs, and /CRLs arrays of stream objects, de-duplicated by content hash. Long-term validation uses two dictionary types — the DSS and the document timestamp dictionary — ISO 32000-2 §12.8.

VRI (Validation Related Information) is a per-signature sub-dictionary keyed by the uppercase hash of that signature’s /Contents value. It indexes the specific /Cert, /OCSP, and /CRL objects for that one signature and may carry a /TU 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. It is caller-enableable for validators that display per-signature status better with it. ETSI EN 319 142-2 describes the same long-term composition — §5.5 — and handler support — §6.3.3.3.

LTV health check

The LTV health check is an Enterprise compliance policy that inspects an existing document for archival completeness. It checks: DSS presence; whether OCSP responses (/OCSPs) or, acceptably, CRLs (/CRLs) are embedded; whether the certificate store (/Certs) is present; and whether per-signature VRI is present. It emits structured findings — informational when a structure is present, an error when the DSS or both OCSP and CRL are absent, and a warning when VRI or the certificate store is missing. Each finding carries the ISO 32000-2 §12.8.4.3 reference.

The check is structural, not cryptographic. It reports whether the structures exist; it does not re-verify the embedded OCSP or CRL data. A present-but-stale OCSP response still reports as present. Revocation material is itself time-bounded: an OCSP response reports good, revoked, or unknown — RFC 6960 §2.2 — bounded by thisUpdate/nextUpdate — RFC 6960 §4.2.

Archival loop

A B-LTA document timestamp is anchored by a TSA certificate with a finite lifetime, written through the document timestamp dictionary — ISO 32000-2 §12.8.5. Before that certificate expires, the archival loop:

Collects fresh revocation material for the TSA certificate chain.
Optionally adds a VRI entry keyed by the TSA certificate hash.
Rewrites the DSS with the updated material.
Adds a new document timestamp over the updated document state via an RFC 3161 exchange — §2.4.1 — whose genTime is the UTC creation instant — §2.4.2.

Each new timestamp covers the previous ones, so validity extends as long as the loop runs before each timestamp certificate’s expiry. Running it on schedule is an operational obligation. The loop raises an error if requested with no TSA configured or under a strict-offline network policy.

API surface (public contract only)

Type	Kind	Role	Stability	Since
`LtvManagerInterface`	interface (`NextPDF\Contracts`)	Long-term producer + archival-loop contract resolved at runtime	stable	1.0.0
`TsaClientInterface`	interface	RFC 3161 TSA client used by the loop	stable	1.0.0
`SignatureLevel`	enum (`NextPDF\Security\Signature`)	B-LTA is the archival level	stable	1.0.0

The LTV health check runs as one Enterprise compliance policy and emits structured findings. Production code depends on the contracts; the concrete archival implementation classes are internal and are not part of the public API.

Conformance

Claim	Standard	Clause
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

All clauses are paraphrased. NextPDF does not reproduce normative text. The archival structures are aligned with the long-term levels defined in ETSI EN 319 142. The cited ETSI anchor is EN 319 142-2, and the ISO/RFC anchors carry the long-term, timestamp, and revocation claims. Whether the archived signature validates is the verifier’s decision against its trust anchors and revocation-freshness policy.

Edge cases & FIPS-mode behavior

Edge cases

The LTV health check is structural; a complete-looking archive can still hold stale revocation data. Treat a pass as presence, not validity.
VRI absence is a warning, not an error: a DSS without VRI is valid.
The archival loop must run before the timestamp certificate’s notAfter; a late run cannot extend the chain.
Strict-offline policy blocks the loop because it needs a fresh TSA token and fresh revocation material.
No TSA configured: the loop raises an error rather than skipping the timestamp.

FIPS-mode behavior

The FIPS 140-3 crypto-policy profile is an Enterprise capability documented with the security module. The archival surface adds only the SHA-256 digest used for the document timestamp and the RFC 3161 exchange. Under the FIPS profile the same DSS, VRI, and document-timestamp structures are produced; the constraint applies to the digest and signing algorithms, not to the archival layout.

Export-control posture

This module concerns cryptographic functionality; treat it as security-sensitive in your own review.

Behavior contract

The DSS, VRI, LTV-health, and archival-loop surface is Enterprise-only. Core produces B-B and B-T (timestamped); a Pro-only deployment produces B-B and B-T but cannot produce or maintain a long-term (B-LT/B-LTA) signature.
The LTV health check reports structural presence of the DSS, OCSP/CRL, certificate store, and VRI; it does not re-verify embedded revocation data cryptographically.
The archival loop rewrites the DSS and adds a new document timestamp over the updated state. It must run before the timestamp certificate expires.
The loop fails closed when no TSA is configured or under a strict-offline network policy.

Core fallback

In a Core-only deployment, the software signer produces PAdES B-B and B-T (Core ships the RFC 3161 timestamp path). Core has no DSS, VRI, LTV-health, or archival-loop surface; a long-term level fails closed via SignatureLevel::isAvailableInEnvironment returning false. The archival surface on this page requires nextpdf/enterprise.

Pro fallback

In a Pro-only deployment, the signing path is the core B-B/B-T baseline plus the Pro remote and cloud-KMS signing workflows. Pro produces no DSS, no VRI, and no document timestamp, and runs no archival loop. A configuration that requests a long-term level resolves the Enterprise producer at runtime through the Core contract; absent nextpdf/enterprise, it fails closed with a named error.

Enterprise boundary note

This page references the public package and the Core contract surface only. Internal mechanism detail stays in the source repository’s internal documentation and is out of scope for this manual.

Deployment boundary

NextPDF Enterprise maintains 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. Indefinite 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’s notAfter.

Publication boundary

This page documents externally observable behavior and the supported public API surface only. Internal namespace paths, helper classes, mechanism tables, runbook filenames, and ticket prefixes are out of scope.

Legal-compliance boundary

This module concerns cryptographic functionality; treat it as security-sensitive in your own review. Alignment with the long-term 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 the archived signature validates is the verifier’s decision against its trust anchors and revocation-freshness policy.