Enterprise edition

Archive: DSS, VRI, LTV health, document timestamps

At a glance

NextPDF Enterprise keeps a long-term signature valid over time. It writes the Document Security Store (DSS) and per-signature VRI, inspects archival completeness with an LTV health check, and re-stamps with a document timestamp before the timestamp certificate expires. This page is behavior-level. It states what the archival surface does, what it inspects, and what the verifier still decides.

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 DSS, VRI, LTV-health, and archival-loop surface is Enterprise-only. NextPDF Core produces the B-B and B-T baseline levels (Core ships the RFC 3161 timestamp path, so B-T does not require a premium package). NextPDF Pro produces the B-B and B-T baseline levels; it produces no DSS or document timestamp. The B-LT and B-LTA levels are produced by Enterprise only, matching the published tier table on the Pro security page. 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 (`nextpdf/enterprise`) only
B-LTA	Document timestamps for archival validity (the archival loop)	Enterprise (`nextpdf/enterprise`) only

This is the canonical level→tier matrix: B-B is the baseline produced by every edition; B-T (timestamped) is produced by Core, Pro, and Enterprise; B-LT and B-LTA are Enterprise-only.

Install

composer require nextpdf/enterprise

nextpdf/enterprise depends on nextpdf/core and nextpdf/pro. The archival surface is part of the Enterprise edition.

Conceptual overview

Long-term validation rests on two structures: the DSS and the document timestamp dictionary — ISO 32000-2 §12.8. The DSS holds the certificates, OCSP responses, and CRLs needed to validate a signature after its certificate expires — ISO 32000-2 §12.8.4.3. VRI is a per-signature index into that material, keyed by the signature’s content hash. The document timestamp dictionary anchors the whole document state in time — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 describes the same long-term shape — §5.5 — and the handler support for it — §6.3.3.3.

A timestamp certificate has a finite lifetime. Before it expires, the archival loop collects fresh revocation material for the timestamp certificate chain, rewrites the DSS, and adds a new document timestamp over the updated state. Each new timestamp covers the previous ones, so the chain of trust extends indefinitely as long as the loop runs on schedule. The timestamp is an RFC 3161 exchange — §2.4.1 — with a UTC genTime (§2.4.2).

The LTV health check inspects an existing document for archival completeness: whether the DSS is present, whether OCSP responses or CRLs are embedded, whether the certificate store and per-signature VRI are present. It checks structural presence; it does not re-verify the cryptographic validity of the embedded OCSP or CRL data. Revocation material has a freshness window: an OCSP response reports good, revoked, or unknown — RFC 6960 §2.2 — bounded by thisUpdate/nextUpdate — RFC 6960 §4.2.

Whether the archived signature validates remains a verifier decision against its trust anchors and freshness policy. The archival surface keeps material complete and time-anchored; it does not assert a trusted outcome.

Why it works this way

The archival surface is reached only through Core contracts — LtvManagerInterface and the SignatureLevel enum — never the concrete Enterprise classes. That boundary is load-bearing. Calling code stays identical from Core to Enterprise, so an upgrade adds capability without a rewrite. The enum resolves the requested level against the installed environment. A long-term request without the Enterprise producer fails closed rather than silently downgrading to an unarchived signature. That matters because a signature that looks long-term but carries no DSS or document timestamp fails validation years later, when no one is watching.

Design background: Long-term validation.

API surface

The archival surface is consumed through the Core long-term contract and the Enterprise compliance-policy surface. Production code depends on the contracts.

Type	Kind	Role	Stability	Since
`LtvManagerInterface`	interface (`NextPDF\Contracts`)	The long-term-validation producer and archival-loop contract	stable	1.0.0
`TsaClientInterface`	interface	RFC 3161 TSA client used by the archival loop	stable	1.0.0
`SignatureLevel`	enum (`NextPDF\Security\Signature`)	PAdES level: B-LTA is the archival level	stable	1.0.0

The LTV health check runs as one Enterprise compliance policy. It emits structured findings — informational when a structure is present, a warning or error when an archival structure is missing — each carrying the ISO 32000-2 §12.8.4.3 reference. The concrete archival classes are internal and are not part of the public API.

Code sample — Quick start

<?php

declare(strict_types=1);

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

use NextPDF\Security\Signature\SignatureLevel;

/**
 * B-LTA is the archival level: DSS plus a document timestamp,
 * maintained by the archival loop. Requires nextpdf/enterprise.
 *
 * @return bool True when this level needs a document timestamp.
 */
function isArchivalLevel(SignatureLevel $level): bool
{
    return $level->requiresDocumentTimestamp();
}

Code sample — Production

<?php

declare(strict_types=1);

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

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

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

    /**
     * Run the archival loop before the timestamp certificate expires.
     *
     * The loop collects fresh revocation material for the timestamp
     * certificate chain, rewrites the DSS, and adds a new document
     * timestamp over the updated state.
     *
     * @throws NextPdfException When no TSA is configured, or under a
     *                          strict-offline network policy.
     */
    public function maintain(): void
    {
        try {
            // The orchestrator drives DSS rewrite + document timestamp via
            // the resolved LtvManagerInterface. Schedule this before the
            // timestamp certificate's notAfter.
            $this->logger->info('archival loop completed');
        } catch (NextPdfException $e) {
            $this->logger->error('archival loop failed', ['reason' => $e->getMessage()]);
            throw $e;
        }
    }
}

Schedule the archival loop ahead of the timestamp certificate’s expiry. A loop that runs after expiry cannot extend the trust chain.

Edge cases & gotchas

The loop is a schedule, not a one-shot. B-LTA validity is only indefinite while the loop keeps running before each timestamp certificate expires. Treat it as an operational obligation.
Health check is structural. The LTV health check reports presence of the DSS, OCSP/CRL, certificate store, and VRI. It does not re-verify the embedded revocation data cryptographically; a present-but-stale OCSP response still reports as present.
VRI absence is a warning, not an error. A DSS without VRI is valid; the health check flags it as a warning because some validators display per-signature status better with VRI.
Strict-offline blocks the loop. The archival loop needs a fresh TSA token and fresh revocation material; it raises an error under a strict-offline network policy.
No TSA means no archival loop. Like B-LTA itself, the loop raises an error when no TSA client is configured.

Performance

A health check is a structural scan of the document and is inexpensive. An archival-loop iteration costs one TSA round trip plus the OCSP/CRL fetches for the timestamp certificate chain; pre-collected material removes the fetch round trips. The 1500 ms wall budget covers one loop iteration on warm connections. The reproducibility profile is structural: each document timestamp embeds its genTime, so re-stamped runs differ in those bytes while the structure is identical.

Security notes

Validity is the verifier’s decision. The archival surface keeps material complete and time-anchored. Whether the verifier accepts it depends on its trust anchors and revocation-freshness policy.
Freshness has a clock. Embedded OCSP/CRL material is bounded by its update fields. The archival loop is what keeps the chain inside a trustworthy window over years.
Structural health is not cryptographic validation. A passing LTV health check means the structures exist, not that every embedded response is currently trustworthy.
See Signature: PAdES B-LT / B-LTA and the threat model section.

Data Residency & PII Mitigations

The archival loop contacts OCSP/CRL responders and the TSA. In a residency-constrained deployment, pre-collect revocation material and use the strict-offline policy where the loop is not required, or place the TSA and responders in-region. The DSS embeds certificates that carry subject identity; the archival surface adds the material required for validation and does not introduce identity beyond the certificate chains it processes.

Safe Telemetry & Log Scrubbing

Health-check findings name the missing structure and the ISO clause, not document content. Archival-loop diagnostics report the loop outcome and the missing-material condition. Neither logs private keys or full certificate bodies. Scrub responder and TSA URLs from logs when those reveal internal infrastructure.

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 for the document timestamp and the RFC 3161 exchange; it introduces no other primitive. 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.

Threat model

Asset	Adversary	Risk	Mitigation
Timestamp chain continuity	Missed loop schedule	Trust chain lapses after a timestamp certificate expires	Operate the archival loop before each timestamp certificate’s expiry
Embedded revocation material	Stale-material acceptance	A verifier trusts expired OCSP/CRL data	Freshness windows bound validity; the loop re-collects before expiry
LTV health signal	Overtrust in a structural pass	A complete-looking archive with stale data	Health check states it is structural, not a cryptographic re-validation
Document timestamp	Unreachable or compromised TSA	No new time anchor	Caller-chosen TSA; loop fails closed when no TSA is configured

Conformance

Claim	Standard	Clause
Long-term validation uses a DSS and a document timestamp dictionary.	ISO 32000-2	§12.8
The DSS holds certificates, OCSP responses, and CRLs; VRI is per-signature.	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. The archival structures described here are aligned with the long-term levels defined in ETSI EN 319 142. The ETSI EN 319 142-1 baseline-levels part is outside the cited evidence set; the cited ETSI evidence is EN 319 142-2, and the ISO and RFC anchors carry the long-term, timestamp, and revocation claims.

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.

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.

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 with a named error. The archival surface described on this page requires nextpdf/enterprise. See Security / Signing (Core).

Pro fallback

In a Pro-only deployment, the supported 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 in a Pro-only deployment fails closed with a message that names the missing Enterprise component. See Pro security.

Enterprise boundary note

The DSS/VRI assembly, the LTV health check, and the archival loop are described at the behavior level only. The internal DSS-rewrite ordering, the per-signature VRI keying internals, the health-finding taxonomy internals, and the loop-scheduling internals are out of scope for the public surface and are 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.

Legal-compliance boundary

It concerns long-term validation and archival of cryptographic signatures. Alignment with the long-term structures defined in ETSI EN 319 142 is a structural statement. Consult your own compliance and legal advisers for your regulatory obligations.