Archive — Référence approfondie

En bref

Ceci est la référence approfondie de la surface d’archivage de NextPDF Enterprise : comment le DSS et la VRI sont structurés, ce que le contrôle de santé LTV inspecte, et comment la boucle d’archivage par horodatage de document étend la validité dans le temps. C’est du niveau comportement et du niveau contrat. Les types d’implémentation Enterprise concrets ne sont intentionnellement pas nommés ici ; la page référence uniquement le paquet public et la surface de contrat Core.

Disponibilité et licence

Cette fonctionnalité est livrée dans NextPDF Enterprise (nextpdf/enterprise) et s’active avec une enveloppe de licence de palier Enterprise. Un déploiement sans cette autorisation ne charge pas les classes de la fonctionnalité. Compare les éditions et obtiens une licence.

La matrice canonique niveau→palier : B-B est la base produite par Core, Pro et Enterprise ; B-T (horodaté) est produit par Core, Pro et Enterprise — Core fournit le chemin d’horodatage RFC 3161, donc B-T n’exige pas de paquet premium ; Pro n’écrit ni DSS ni horodatage de document ; B-LT et B-LTA sont produits uniquement par Enterprise. Dans un déploiement Pro uniquement, demander un niveau de long terme échoue de manière fermée avec un message qui nomme le composant Enterprise manquant.

Niveau PAdES	Ajoute	Édition productrice
B-B	Signature CMS avec attributs signés	Core, Pro, Enterprise
B-T	Horodatage RFC 3161 de confiance sur la valeur de signature	Core, Pro, Enterprise
B-LT	Document Security Store avec matériel de validation	Enterprise uniquement
B-LTA	Horodatage de document sur le DSS (boucle d’archivage)	Enterprise uniquement

Structure DSS et VRI

Le DSS est un dictionnaire au niveau du Catalogue qui porte le matériel de validation dont un vérificateur a besoin après l’expiration d’un certificat de signature — ISO 32000-2 §12.8.4.3. Il expose des tableaux /Certs, /OCSPs et /CRLs d’objets-flux, dédupliqués par hash de contenu. La validation à long terme utilise deux types de dictionnaires — le DSS et le dictionnaire d’horodatage de document — ISO 32000-2 §12.8.

La VRI (Validation Related Information) est un sous-dictionnaire par signature, indexé par le hash en majuscules de la valeur /Contents de cette signature. Elle indexe les objets /Cert, /OCSP et /CRL spécifiques de cette signature unique et peut porter une entrée de temps de validation /TU. La VRI est désactivée par défaut : ETSI EN 319 142-1 V1.2.1 §5.4 déconseille la VRI dans le DSS pour les nouveaux documents. Elle est activable par l’appelant pour les vérificateurs qui affichent mieux le statut par signature avec elle. ETSI EN 319 142-2 décrit la même composition à long terme — §5.5 — et la prise en charge par le gestionnaire — §6.3.3.3.

Contrôle de santé LTV

Le contrôle de santé LTV est une politique de conformité Enterprise qui inspecte un document existant pour vérifier la complétude de l’archivage. Il vérifie : la présence du DSS ; si des réponses OCSP (/OCSPs) ou, de manière acceptable, des CRL (/CRLs) sont incorporées ; si le magasin de certificats (/Certs) est présent ; et si une VRI par signature est présente. Il émet des constats structurés — informatif quand une structure est présente, une erreur quand le DSS ou à la fois l’OCSP et la CRL sont absents, et un avertissement quand la VRI ou le magasin de certificats manque. Chaque constat porte la référence ISO 32000-2 §12.8.4.3.

Le contrôle est structurel, pas cryptographique. Il indique si les structures existent ; il ne revérifie pas les données OCSP ou CRL incorporées. Une réponse OCSP présente mais périmée est tout de même signalée comme présente. Le matériel de révocation est lui-même limité dans le temps : une réponse OCSP indique good, revoked ou unknown — RFC 6960 §2.2 — borné par thisUpdate/nextUpdate — RFC 6960 §4.2.

Boucle d’archivage

Un horodatage de document B-LTA est ancré par un certificat de TSA de durée de vie finie, écrit via le dictionnaire d’horodatage de document — ISO 32000-2 §12.8.5. Avant l’expiration de ce certificat, la boucle d’archivage :

1. Collecte du matériel de révocation frais pour la chaîne de certificats de la TSA.
2. Ajoute optionnellement une entrée VRI indexée par le hash du certificat de la TSA.
3. Réécrit le DSS avec le matériel mis à jour.
4. Ajoute un nouvel horodatage de document sur l’état de document mis à jour via un échange RFC 3161 — §2.4.1 — dont le genTime est l’instant de création en UTC — §2.4.2.

Chaque nouvel horodatage couvre les précédents, de sorte que la validité s’étend tant que la boucle s’exécute avant l’expiration du certificat de chaque horodatage. L’exécuter selon un calendrier est une obligation opérationnelle. La boucle lève une erreur si elle est demandée sans TSA configurée ou sous une politique réseau strictement hors-ligne.

Surface d’API (contrat public uniquement)

Type	Genre	Rôle	Stabilité	Depuis
LtvManagerInterface	interface (NextPDF\Contracts)	Contrat de producteur à long terme + boucle d’archivage résolu à l’exécution	stable	1.0.0
TsaClientInterface	interface	Client de TSA RFC 3161 utilisé par la boucle	stable	1.0.0
SignatureLevel	énumération (NextPDF\Security\Signature)	B-LTA est le niveau d’archivage	stable	1.0.0

Le contrôle de santé LTV s’exécute comme une seule politique de conformité Enterprise et émet des constats structurés. Le code de production dépend des contrats ; les classes d’implémentation d’archivage concrètes sont internes et ne font pas partie de l’API publique.

Conformité

Revendication	Norme	Clause
La LTV utilise un DSS et un dictionnaire d’horodatage de document.	ISO 32000-2	§12.8
Le DSS est le dictionnaire qui est la valeur de la clé DSS dans le catalogue du document ; contient Certs, OCSPs, CRLs.	ISO 32000-2	§12.8.4.3
Structure du dictionnaire d’horodatage de document.	ISO 32000-2	§12.8.5
DSS + horodatages de document pour les signatures à long terme.	ETSI EN 319 142-2	§5.5
Le gestionnaire prend en charge DSS + horodatages de document.	ETSI EN 319 142-2	§6.3.3.3
La requête RFC 3161 renvoie TSTInfo ; genTime est l’instant de création en UTC.	RFC 3161	§2.4.1, §2.4.2
OCSP good/revoked/unknown borné par thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2

Toutes les clauses sont paraphrasées. NextPDF ne reproduit pas de texte normatif. NextPDF ne formule aucune revendication de certification PAdES : les structures d’archivage sont alignées sur les niveaux de long terme définis par ETSI EN 319 142 ; aucun résultat de test de conformance ni attestation par un tiers n’est revendiqué. La partie ETSI EN 319 142-1 sur les niveaux de base est hors de l’ensemble de preuves cité ; l’ancrage ETSI cité est EN 319 142-2, et les ancrages ISO/RFC portent les revendications de long terme, d’horodatage et de révocation — la même posture de divulgation que la référence de signature Core. Le fait que la signature archivée valide est la décision du vérificateur par rapport à ses ancres de confiance et à sa politique de fraîcheur de révocation.

Cas limites et comportement en mode FIPS

Cas limites

• Le contrôle de santé LTV est structurel ; une archive d’apparence complète peut tout de même contenir des données de révocation périmées. Traite un succès comme une présence, pas comme une validité.
• L’absence de VRI est un avertissement, pas une erreur : un DSS sans VRI est valide.
• La boucle d’archivage doit s’exécuter avant le notAfter du certificat d’horodatage ; une exécution tardive ne peut pas étendre la chaîne.
• La politique strictement hors-ligne bloque la boucle, car elle a besoin d’un jeton TSA frais et de matériel de révocation frais.
• Aucune TSA configurée : la boucle lève une erreur plutôt que d’ignorer l’horodatage.

Comportement en mode FIPS

Le profil de politique cryptographique FIPS 140-3 est une capacité Enterprise documentée avec le module de sécurité. La surface d’archivage n’ajoute que le condensé SHA-256 utilisé pour l’horodatage de document et l’échange RFC 3161. Sous le profil FIPS, les mêmes structures DSS, VRI et horodatage de document sont produites ; la contrainte s’applique aux algorithmes de condensé et de signature, pas à la disposition d’archivage.

Posture de contrôle des exportations

Ce module concerne des fonctionnalités cryptographiques ; traite-le comme sensible du point de vue de la sécurité lors de ta propre revue.

Contrat de comportement

• La surface DSS, VRI, santé LTV et boucle d’archivage est réservée à Enterprise. Core produit B-B et B-T (horodaté) ; un déploiement Pro uniquement produit B-B et B-T mais ne peut ni produire ni maintenir une signature à long terme (B-LT/B-LTA).
• Le contrôle de santé LTV signale la présence structurelle du DSS, de l’OCSP/CRL, du magasin de certificats et de la VRI ; il ne revérifie pas cryptographiquement les données de révocation incorporées.
• La boucle d’archivage réécrit le DSS et ajoute un nouvel horodatage de document sur l’état mis à jour. Elle doit s’exécuter avant l’expiration du certificat d’horodatage.
• La boucle échoue de manière fermée lorsqu’aucune TSA n’est configurée ou sous une politique réseau strictement hors-ligne.

Repli Core

Dans un déploiement Core uniquement, le signataire logiciel produit du PAdES B-B et B-T (Core fournit le chemin d’horodatage RFC 3161). Core n’a aucune surface DSS, VRI, santé LTV ou boucle d’archivage ; un niveau de long terme échoue de manière fermée via SignatureLevel::isAvailableInEnvironment renvoyant false. La surface d’archivage de cette page exige nextpdf/enterprise.

Repli Pro

Dans un déploiement Pro uniquement, le chemin de signature est la base B-B/B-T de Core plus les workflows de signature à distance et par KMS cloud de Pro. Pro ne produit ni DSS, ni VRI, ni horodatage de document, et n’exécute aucune boucle d’archivage. Une configuration qui demande un niveau de long terme résout le producteur Enterprise à l’exécution via le contrat Core ; en l’absence de nextpdf/enterprise, elle échoue de manière fermée avec une erreur nommée.

Note sur la frontière Enterprise

Cette page référence uniquement le paquet public et la surface de contrat Core. Le détail des mécanismes internes reste dans la documentation interne du dépôt source et est hors du périmètre de ce manuel.

Frontière de déploiement

NextPDF Enterprise maintient le matériel de validation ; il s’intègre à des répondeurs OCSP/CRL fournis par l’appelant et à une TSA RFC 3161. Il n’exploite, n’héberge ni ne garantit la disponibilité de ces répondeurs ou de la TSA. La validité indéfinie dépend des répondeurs, de la TSA, du calendrier de la boucle d’archivage et de l’opérateur — pas de NextPDF Enterprise seul. L’opérateur possède la sélection et l’accessibilité de la TSA, l’accès aux répondeurs de révocation ou le matériel pré-collecté, la politique réseau et l’exécution de la boucle d’archivage avant le notAfter de chaque certificat d’horodatage.

Frontière de publication

Cette page documente uniquement le comportement observable de l’extérieur et la surface d’API publique prise en charge. Les chemins d’espace de noms internes, les classes utilitaires, les tables de mécanismes, les noms de fichiers de runbook et les préfixes de ticket sont hors périmètre.

Frontière de conformité légale

Ce module concerne des fonctionnalités cryptographiques ; traite-le comme sensible du point de vue de la sécurité lors de ta propre revue. L’alignement sur les structures de long terme définies par ETSI EN 319 142 est un énoncé structurel, pas un avis juridique ni une certification. NextPDF ne formule aucune revendication de certification PAdES. Le fait que la signature archivée valide est la décision du vérificateur par rapport à ses ancres de confiance et à sa politique de fraîcheur de révocation.

Voir aussi

• Archive (aperçu de la fonctionnalité) — la page de fonctionnalité que cette référence étaye.
• Référence approfondie Signature — le producteur B-LT / B-LTA.
• Sécurité / Signature (Core) — CMS, RFC 3161, RFC 5280, OCSP/CRL.
• Sécurité Pro — la base B-B et la frontière Enterprise.
• Mappage de la base PAdES