Signature — Référence approfondie

En bref

Voici la référence approfondie du producteur à long terme de NextPDF Enterprise : comment une signature B-LT ou B-LTA est assemblée, comment le matériel de révocation est collecté et appliqué, comment l’horodatage de document ancre le document et comment la frontière Pro est appliquée. Elle est au niveau du comportement et du contrat. Les types d’implémentation Enterprise concrets ne sont délibérément pas nommés ici ; la page ne référence que le paquet public et la surface de contrat du Core.

Disponibilité & licence

Cette capacité est livrée dans NextPDF Enterprise (nextpdf/enterprise) et s’active avec une enveloppe de licence de palier Enterprise. Un déploiement sans ce droit d’accès ne charge pas les classes de la capacité. Comparer les éditions et obtenir une licence.

La matrice canonique niveau→palier : B-B est la base produite par le Core, Pro et Enterprise ; B-T (horodaté) est produit par le Core, Pro et Enterprise — le Core livre le chemin d’horodatage RFC 3161, de sorte que B-T ne nécessite aucun paquet premium ; B-LT et B-LTA (DSS, VRI, horodatage de document) sont produits par Enterprise uniquement. Dans un déploiement Pro uniquement, demander B-LT ou B-LTA échoue de manière sûre : le SignatureLevel::isAvailableInEnvironment du Core renvoie faux lorsque le producteur à long terme Enterprise est absent, et l’orchestrateur du Core lève une erreur nommée plutôt que de dégrader silencieusement le niveau.

Niveau PAdES	Ajoute	Édition du producteur
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

Modèle conceptuel

Une signature B-LT est une signature B-T plus un Document Security Store. Le DSS est un dictionnaire au niveau du Catalogue qui contient les flux de certificats, de réponses OCSP et de CRL dont un vérificateur a besoin une fois le certificat de signature expiré — ISO 32000-2 §12.8.4.3. La validation à long terme repose sur deux types de dictionnaires — un DSS et un dictionnaire d’horodatage de document — ISO 32000-2 §12.8. La signature CMS elle-même est stockée encodée en DER dans /Contents — ISO 32000-2 §12.8.1.

Une signature B-LTA ajoute un horodatage de document sur l’état complet du document, y compris le DSS, écrit via le dictionnaire d’horodatage de document — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 décrit la même composition à long terme — §5.5 — ainsi que la prise en charge par le gestionnaire — §6.3.3.3.

Flux du producteur

1. Construire la chaîne. Le certificat du signataire plus tout intermédiaire fourni par l’appelant forment la chaîne, signataire en premier, vers l’ancre de confiance — RFC 5280 §6.1.
2. Collecter le matériel de révocation. Pour chaque certificat non racine, le producteur interroge d’abord OCSP. Une réponse OCSP indique good, revoked ou unknown — RFC 6960 §2.2 — et est bornée dans le temps par thisUpdate/nextUpdate — RFC 6960 §4.2. Si OCSP est indisponible, il se rabat sur une CRL, avec prise en charge des delta-CRL ; une CRL de base et un delta facultatif sont ajoutés comme entrées DSS distinctes.
3. Écrire le DSS. Les certificats, les réponses OCSP et les CRL sont écrits comme objets flux PDF individuels ; les doublons sont dédupliqués par empreinte de contenu. Le dictionnaire DSS les référence via /Certs, /OCSPs, /CRLs.
4. VRI par signature (opt-in). Une entrée VRI, indexée par l’empreinte en majuscules de la valeur /Contents de la signature, indexe les certs/OCSP/CRL spécifiques à cette signature, avec une entrée de temps de validation facultative. Le VRI est désactivé par défaut : ETSI EN 319 142-1 V1.2.1 §5.4 déconseille le VRI dans le DSS pour les nouveaux documents ; certains validateurs affichent tout de même mieux le statut à long terme avec lui, il est donc activable par l’appelant.
5. Horodatage de document (B-LTA). Après l’écriture du DSS, un dictionnaire /DocTimeStamp avec /SubFilter /ETSI.RFC3161 est ajouté avec des emplacements réservés pour ByteRange et /Contents. Une fois le fichier complet assemblé, le producteur calcule l’empreinte SHA-256 sur le ByteRange, demande un jeton RFC 3161 — §2.4.1 — et intègre le jeton DER ; genTime est l’instant UTC de création du jeton — §2.4.2.

Application de la révocation

Le producteur résout un mode d’application avec cette préséance : un mode d’application structuré explicite l’emporte ; sinon un booléen explicite (déprécié) se mappe sur strict ou permissif ; sinon la valeur par défaut est strict (échec sûr / fail-closed).

Sous application stricte, une réponse OCSP manquante et une CRL manquante pour tout certificat non racine lèvent une erreur plutôt que de n’émettre qu’un avertissement. La valeur par défaut en échec sûr existe afin qu’un PDF « B-LT » ne puisse pas être produit sans aucun matériel de révocation dans le DSS tout en affichant le niveau à long terme. Le flux permissif (avertissement seul) doit être choisi explicitement (opt-in). Sous une politique réseau strictement hors ligne, aucune récupération OCSP/CRL n’est effectuée ; seul le matériel intégré au DSS est utilisé, et la condition de matériel manquant est traitée par la même règle d’application.

Boucle d’archivage

L’horodatage de document B-LTA est ancré par un certificat de TSA qui expire lui-même. La boucle d’archivage, exécutée avant cette expiration, collecte du matériel de révocation frais pour la chaîne de certificats de la TSA, réécrit le DSS, ajoute facultativement une entrée VRI indexée par l’empreinte du certificat de la TSA, et ajoute un nouvel horodatage de document sur l’état mis à jour. Chaque nouvel horodatage couvre les précédents. Exécuter la boucle selon le calendrier est une obligation opérationnelle ; le producteur lève une erreur si la boucle est demandée sans aucune TSA configurée ou sous politique strictement hors ligne. La surface d’archivage complète est documentée dans la référence approfondie Archive.

Surface d’API (contrat public uniquement)

Type	Catégorie	Rôle	Stabilité	Depuis
SignerInterface	interface (NextPDF\Contracts)	Le contrat de signature du Core	stable	1.0.0
LtvManagerInterface	interface (NextPDF\Contracts)	Le contrat du producteur à long terme + boucle d’archivage résolu à l’exécution	stable	1.0.0
TsaClientInterface	interface	Client TSA RFC 3161 que le producteur appelle	stable	1.0.0
SignatureLevel	enum (NextPDF\Security\Signature)	Sélecteur B-B, B-T, B-LT, B-LTA et sonde de disponibilité	stable	1.0.0

SignatureLevel::requiresDss → vrai pour B-LT, B-LTA. requiresDocumentTimestamp → vrai uniquement pour B-LTA. requiresTimestamp → vrai pour B-T, B-LT, B-LTA. Le code de production dépend de ces contrats ; les classes d’implémentation Enterprise concrètes sont internes et ne font pas partie de l’API publique.

Conformité

Revendication	Norme	Clause
Signature/horodatage stocké encodé en DER dans /Contents.	ISO 32000-2	§12.8.1
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 ; il 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 UTC de création.	RFC 3161	§2.4.1, §2.4.2
OCSP good/revoked/unknown borné par thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2
Entrées de validation de chemin vers une ancre de confiance.	RFC 5280	§6.1

Toutes les clauses sont paraphrasées. NextPDF ne reproduit pas le texte normatif. NextPDF ne formule aucune revendication de certification PAdES : le producteur écrit des structures alignées sur les niveaux B-LT et B-LTA définis dans ETSI EN 319 142 ; aucun résultat de test de conformité ni aucune attestation par un tiers n’est revendiqué. La partie sur les niveaux de base d’ETSI EN 319 142-1 se situe hors de l’ensemble de preuves cité, de sorte que l’ancre ETSI citée est EN 319 142-2 et que les ancres ISO/RFC portent les revendications à long terme et d’horodatage — la même posture de divulgation que la référence de signature du Core. Le fait qu’une signature produite se vérifie est la décision du vérificateur au regard de ses ancres de confiance et de sa politique de fraîcheur de révocation ; le producteur intègre du matériel et n’affirme pas un résultat de confiance.

Cas limites & comportement en mode FIPS

Cas limites

• Le DSS doit être écrit avant l’horodatage de document ; un horodatage écrit avant le DSS ne couvre pas le matériel de validation.
• L’application stricte (par défaut) lève une erreur lorsque le matériel de révocation est manquant pour un certificat non racine. Le mode permissif est en opt-in.
• B-LTA sans aucune TSA configurée lève une erreur plutôt que de produire B-LT.
• Politique strictement hors ligne : aucun accès réseau OCSP/CRL/TSA ; B-LTA n’est pas accessible en mode strictement hors ligne.
• Le jeton d’horodatage de document dispose d’un espace réservé borné ; un jeton qui le dépasse lève une erreur plutôt que de le tronquer.

Comportement en mode FIPS

Le profil de politique cryptographique FIPS 140-3 est une capacité Enterprise documentée avec le module de sécurité. Le producteur à long terme n’ajoute que l’empreinte SHA-256 utilisée pour l’horodatage de document et l’échange RFC 3161 ; la primitive de signature est celle du signataire du Core. Sous le profil FIPS, les mêmes structures DSS, VRI et d’horodatage de document sont produites ; la contrainte s’applique aux algorithmes de signature et d’empreinte, et non à la disposition du DSS. La garde matérielle des clés via PKCS#11 est documentée avec le module de sécurité et est hors du périmètre de cette page.

Contrat de comportement

• Le Core produit B-B et B-T (B-T ajoute l’horodatage RFC 3161 sur la valeur de signature). Pro produit B-B et B-T via la même pile Core. B-LT et B-LTA sont produits par Enterprise uniquement.
• Le producteur écrit le DSS (B-LT) et un horodatage de document sur le DSS (B-LTA). Il intègre du matériel de validation ; il n’affirme pas un résultat de vérification de confiance.
• La valeur par défaut d’application de la révocation en échec sûr lève une erreur lorsque le matériel de révocation est manquant pour un certificat non racine, sauf si l’appelant choisit le flux permissif.
• B-LTA nécessite une TSA configurée ; sans aucune, l’étape B-LTA lève une erreur plutôt que de se dégrader en B-LT.

Repli sur le Core

Dans un déploiement Core uniquement, le signataire logiciel produit PAdES B-B et B-T via SignerInterface ; le Core livre le chemin d’horodatage RFC 3161, de sorte que B-T ne nécessite aucun paquet premium. Le Core n’a aucun producteur de DSS, VRI ni d’horodatage de document ; une demande B-LT ou B-LTA échoue de manière sûre via SignatureLevel::isAvailableInEnvironment qui renvoie faux.

Repli sur Pro

Dans un déploiement Pro uniquement, le chemin de signature est la base B-B/B-T plus les workflows de signature distante et cloud-KMS. Pro ne produit aucun DSS ni horodatage de document. RemoteSigningConfig porte l’enum SignatureLevel du Core, mais un niveau à long terme (B-LT/B-LTA) est une valeur déclarée par anticipation que Pro ne traite pas ; le producteur à long terme se résout à l’exécution via le contrat du Core et est livré dans nextpdf/enterprise.

Note sur la frontière Enterprise

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 intègre du 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 pas, n’héberge pas et ne garantit pas la disponibilité de ces répondeurs ni de la TSA. La validité à long terme dépend des répondeurs, de la TSA, du calendrier de la boucle d’archivage et de l’opérateur — et non 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 l’expiration 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 d’assistance, 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

L’alignement avec les structures B-LT et B-LTA définies dans ETSI EN 319 142 est une déclaration structurelle, et non un avis juridique ni une certification. NextPDF ne formule aucune revendication de certification PAdES. Le fait qu’une signature produite se vérifie est la décision du vérificateur au regard de ses ancres de confiance et de sa politique de fraîcheur de révocation.

Voir aussi

• Signature (aperçu de la capacité)
• Référence approfondie Archive — maintenance DSS/VRI, santé LTV, boucle d’archivage.
• Sécurité / Signature (Core) — CMS, RFC 3161, RFC 5280, OCSP/CRL.
• Sécurité Pro — la base B-B et la frontière Enterprise.
• Correspondance des bases PAdES