Archive — 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 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.

Edition gate

Requires NextPDF Enterprise (nextpdf/enterprise). The DSS, VRI, LTV-health, and archival-loop surface is Enterprise-only. 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 and 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.

License feature flag

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

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:

1. Collects fresh revocation material for the TSA certificate chain.
2. Optionally adds a VRI entry keyed by the TSA certificate hash.
3. Rewrites the DSS with the updated material.
4. 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)

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

All clauses are paraphrased. NextPDF does not reproduce normative text. NextPDF makes no PAdES certification claim: the archival structures are aligned with the long-term 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; the cited ETSI anchor is EN 319 142-2, and the ISO/RFC anchors carry the long-term, timestamp, and revocation claims — the same disclosure posture as the Core signing reference. 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 is flagged export_control_class: legal-review-required. Legal sign-off is required before publish: true. See LEGAL_SIGNOFF_PACKET.md.

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 only and 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 Pro B-B baseline plus remote and cloud-KMS signing strategies. 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. Concrete Enterprise archival implementation types are intentionally not named. The internal DSS-rewrite ordering, the VRI-keying internals, the health-finding taxonomy internals, and the loop-scheduling internals are out of scope and not reproduced here.

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.

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 health-taxonomy 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 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.

See also

• Archive (public landing)
• Signature deep reference — the B-LT / B-LTA producer.
• Security / Signing (Core) — CMS, RFC 3161, RFC 5280, OCSP/CRL.
• Pro security — the B-B baseline and the Enterprise boundary.
• PAdES baseline mapping