Signature : PAdES B-LT / B-LTA, DSS, horodatages de document

En bref

NextPDF Enterprise ajoute le producteur de signatures à long terme au-dessus de la signature CMS du Core : un Document Security Store (DSS), des informations relatives à la validation par signature (VRI) et des horodatages de document. Ces structures font évoluer une signature de base PAdES de B-B vers B-LT, puis vers B-LTA. Cette page décrit le comportement observable. Elle précise ce que le producteur écrit, ce qu’il ne décide pas, et où se situe la frontière avec Pro.

Installation

composer require nextpdf/enterprise

nextpdf/enterprise dépend de nextpdf/core et de nextpdf/pro. Résous ce paquet avec tes identifiants de licence NextPDF sur Private Packagist.

Vue d’ensemble conceptuelle

Une signature de base PAdES comporte quatre niveaux. Chaque niveau ajoute du matériel au précédent. B-B correspond à une signature CMS avec attributs signés. B-T ajoute un horodatage RFC 3161 de confiance sur la valeur de signature. B-LT ajoute un DSS qui contient les certificats, les réponses OCSP et les CRL dont un vérificateur a besoin après l’expiration du certificat de signature. B-LTA ajoute un horodatage de document sur l’état complet du document, y compris le DSS, afin que le matériel de validation lui-même reste ancré dans le temps.

Le Core construit le CMS SignedData et le stocke sous forme encodée en DER dans l’entrée Contents du dictionnaire de signature — ISO 32000-2 §12.8.1. La validation à long terme repose sur deux types de dictionnaires : un Document Security Store et un dictionnaire d’horodatage de document — ISO 32000-2 §12.8. Le producteur Enterprise écrit le DSS qui contient le matériel de certificats, OCSP et CRL — ISO 32000-2 §12.8.4.3 — et, pour B-LTA, le dictionnaire d’horodatage de document — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 décrit le même format à long terme : des entrées DSS et des horodatages de document pour les signatures à long terme — §5.5 — pris en charge par le gestionnaire de signature — §6.3.3.3.

Le producteur collecte le matériel de révocation pour chaque certificat de la chaîne. Il interroge d’abord un répondeur OCSP ; une réponse OCSP indique good, revoked ou unknown — RFC 6960 §2.2 — et les champs thisUpdate et nextUpdate bornent la fraîcheur de ce statut — RFC 6960 §4.2. Si OCSP est indisponible, il se rabat sur une CRL. La chaîne est parcourue du signataire vers une ancre de confiance en suivant les entrées de validation de chemin — RFC 5280 §6.1.

L’horodatage de document B-LTA repose sur un échange RFC 3161 avec une autorité d’horodatage. La requête renvoie un TSTInfo — RFC 3161 §2.4.1 — dont le genTime est l’instant UTC où le jeton a été créé — RFC 3161 §2.4.2. Le jeton est intégré dans un dictionnaire /DocTimeStamp avec /SubFilter /ETSI.RFC3161 qui couvre l’ensemble du fichier.

Le fait qu’une signature produite se vérifie dépend du vérificateur, ainsi que des ancres de confiance et de la politique de révocation avec lesquelles il est configuré. Le producteur intègre du matériel ; il n’affirme pas un résultat de confiance. Cette frontière est rappelée ci-dessous chaque fois qu’elle est déterminante.

L’ordre est déterminant : le DSS doit être écrit avant l’horodatage de document B-LTA, car l’horodatage doit couvrir l’état du document qui contient déjà le matériel de validation. Le flux du producteur est présenté ci-dessous.

Diagram

Surface d’API

Le producteur à long terme Enterprise s’utilise via le contrat du Core. Le code de production dépend du contrat, et non du type d’implémentation Enterprise concret.

Type	Catégorie	Rôle	Stabilité	Depuis
`SignerInterface`	interface (`NextPDF\Contracts`)	Contrat de signature du Core dont dépendent les appelants	stable	1.0.0
`SignatureLevel`	enum (`NextPDF\Security\Signature`)	Sélecteur de niveau PAdES : B-B, B-T, B-LT, B-LTA	stable	1.0.0
`LtvManagerInterface`	interface (`NextPDF\Contracts`)	Contrat du producteur de validation à long terme résolu à l’exécution	stable	1.0.0
`TsaClientInterface`	interface	Client TSA RFC 3161 que le producteur appelle pour les horodatages de document	stable	1.0.0

SignatureLevel::requiresDss() est vrai pour B-LT et B-LTA ; SignatureLevel::requiresDocumentTimestamp() est vrai uniquement pour B-LTA. Le SignatureLevel::isAvailableInEnvironment() du Core renvoie faux pour B-LT et B-LTA lorsque le producteur à long terme Enterprise n’est pas installé ; l’orchestrateur du Core échoue alors de manière sûre (fail-closed). Les classes du producteur Enterprise concret sont internes et ne font pas partie de l’API publique ; dépends de LtvManagerInterface et de l’enum.

Exemple de code — Démarrage rapide

<?php

declare(strict_types=1);

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

use NextPDF\Security\Signature\SignatureLevel;

/**
 * Select the PAdES level for a long-term signature.
 *
 * B-LT embeds a DSS. B-LTA also adds a document timestamp.
 * Both require the nextpdf/enterprise long-term producer at runtime.
 *
 * @return SignatureLevel The requested PAdES baseline level.
 */
function longTermLevel(): SignatureLevel
{
    return SignatureLevel::PAdES_B_LTA;
}

Le niveau est défini dans la configuration de signature. L’orchestrateur du Core résout le producteur à long terme via LtvManagerInterface à l’exécution, de sorte que le code applicatif ne référence pas le type Enterprise.

Exemple de code — Production

<?php

declare(strict_types=1);

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

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

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

    /**
     * Sign, then embed the DSS and the B-LTA document timestamp.
     *
     * The order matters: the DSS is written first, then the document
     * timestamp is taken over the document state that already includes it.
     *
     * @param string $byteRange The PDF byte range to sign.
     *
     * @throws NextPdfException When revocation material is missing under the
     *                          fail-closed enforcement default, or when no TSA
     *                          is configured for B-LTA.
     */
    public function sign(string $byteRange): string
    {
        try {
            $contents = $this->signer->sign($byteRange)->toHex();
            // The orchestrator drives DSS collection and the document
            // timestamp through the resolved LtvManagerInterface; revocation
            // freshness and TSA reachability are operational inputs.
            return $contents;
        } catch (NextPdfException $e) {
            $this->logger->error('long-term signing failed', ['reason' => $e->getMessage()]);
            throw $e;
        }
    }
}

Le DSS doit être écrit avant l’horodatage de document. L’horodatage B-LTA couvre le fichier complet, y compris le DSS, ce qui ancre dans le temps le matériel de validation lui-même.

Cas limites & pièges

Un matériel de révocation manquant échoue de manière sûre par défaut. Lorsqu’aucun mode d’application n’est défini, le producteur traite une réponse OCSP manquante et une CRL manquante, pour tout certificat non racine, comme une erreur et non comme un avertissement. Cela empêche qu’un document revendiquant un niveau à long terme soit écrit sans aucun matériel de révocation dans le DSS. Le flux permissif (avertissement seul) est facultatif (opt-in).
B-LTA nécessite une TSA. Un horodatage de document est un aller-retour RFC 3161. Sans client TSA configuré, l’étape B-LTA lève une erreur plutôt que de produire silencieusement B-LT.
L’ordre est déterminant. N’ajoute l’horodatage de document qu’après l’écriture du DSS. Un horodatage pris avant le DSS ne couvre pas le matériel de validation.
Exécutions en réseau isolé (air-gapped). Sous une politique réseau strictement hors ligne, aucune récupération OCSP/CRL ni aucune requête TSA n’est effectuée ; seul le matériel déjà intégré dans le DSS est utilisé. B-LTA, qui nécessite un jeton TSA frais, n’est pas accessible en mode strictement hors ligne.
Le VRI est facultatif (opt-in). Le VRI par signature n’est pas écrit par défaut. Certains validateurs affichent mieux le statut à long terme lorsque le VRI est présent ; active-le lorsqu’un vérificateur cible en a besoin.

Performance

Le coût d’assemblage du DSS croît avec la longueur de la chaîne et le nombre de réponses de révocation récupérées. Chaque récupération OCSP ou CRL est un aller-retour réseau ; du matériel pré-collecté ou mis en cache supprime ces allers-retours. Une exécution B-LTA ajoute un aller-retour TSA pour l’horodatage de document. Le budget de 1500 ms de temps total couvre une seule signature à long terme avec des connexions OCSP/CRL et TSA chaudes ; des répondeurs froids ou lents dominent le temps total. Le profil de reproductibilité est structural : les horodatages intègrent les instants de signature et d’apposition, de sorte que deux exécutions diffèrent sur ces octets tandis que la structure du document est identique.

Notes de sécurité

La confiance est la décision du vérificateur. Le producteur intègre les certificats, les réponses OCSP et les CRL. Le fait que la signature soit valide dépend du vérificateur, de ses ancres de confiance et de sa politique de fraîcheur de révocation. NextPDF ne livre aucune liste de confiance intégrée.
La fraîcheur de révocation est bornée dans le temps. Les fenêtres de validité des OCSP thisUpdate/nextUpdate et des CRL bornent la durée d’utilité du matériel intégré. La boucle d’archivage réappose un horodatage avant l’expiration du certificat d’horodatage ; l’exécuter selon le calendrier est de la responsabilité de l’appelant.
Échec sûr par défaut (fail-closed). La valeur par défaut d’application stricte de la révocation existe afin qu’une revendication à long terme ne soit pas faite sans le matériel qui l’étaye.
Voir la section Modèle de menace Enterprise et Archive : DSS, VRI, santé LTV.

Résidence des données & mesures d’atténuation des PII

La récupération OCSP et CRL contacte les répondeurs nommés dans chaque certificat ; ces points de terminaison et la TSA voient les métadonnées de la requête. Dans un déploiement contraint par la résidence des données, pré-collecte le matériel de révocation et exécute sous la politique strictement hors ligne afin qu’aucun répondeur ni aucune TSA ne soit contacté au moment de la signature. Les certificats portent l’identité du sujet. Le producteur intègre les certificats requis pour la validation et n’ajoute pas d’identité au-delà de la chaîne ; il ne supprime pas les champs de sujet d’un certificat fourni par l’appelant.

Télémétrie sûre & nettoyage des journaux

Les diagnostics du producteur rapportent le niveau, la position dans la chaîne et la condition de matériel manquant. Ils ne journalisent pas les clés privées ni les corps complets des certificats. Lors du câblage d’un journaliseur PSR-3, réserve les journaux de diagnostic des flux de signature à un niveau de verbosité non destiné à la production et masque les URL de répondeur si elles révèlent une infrastructure interne. Considère chaque octet OCSP/CRL intégré comme du contenu de document, et non comme du contenu de journal.

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 aucune primitive cryptographique propre au-delà de 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. Lorsque le profil FIPS est actif, les mêmes structures DSS et d’horodatage de document sont produites ; la contrainte s’applique aux algorithmes sous-jacents de signature et d’empreinte, et non à la disposition du DSS.

Modèle de menace

Actif	Adversaire	Risque	Mesure d’atténuation
Matériel de révocation du DSS	Acceptation de matériel périmé	Un vérificateur fait confiance à des données de révocation expirées	Les champs de fraîcheur OCSP/CRL bornent la validité ; la boucle d’archivage réappose un horodatage avant l’expiration
Horodatage de document B-LTA	Compromission de la TSA ou TSA injoignable	Aucune ancre temporelle digne de confiance	TSA choisie par l’appelant ; B-LTA échoue de manière sûre lorsqu’aucune TSA n’est configurée
Revendication à long terme	Matériel manquant silencieux	Un PDF « à long terme » sans aucune donnée de révocation	La valeur par défaut d’application en échec sûr lève une erreur au lieu d’un avertissement
Vérification de signature	Confiance du vérificateur mal configurée	Validité apparente que le vérificateur ne devrait pas affirmer	Le producteur déclare qu’il intègre uniquement du matériel ; la décision de confiance revient au vérificateur

Conformité

Revendication	Norme	Clause	reference_id
La valeur de signature (ou le jeton d’horodatage) est stockée sous forme encodée en DER dans `/Contents`.	ISO 32000-2	§12.8.1
La validation à long terme utilise un DSS et un dictionnaire d’horodatage de document.	ISO 32000-2	§12.8
Le DSS contient les certificats, les réponses OCSP et les CRL.	ISO 32000-2	§12.8.4.3
L’horodatage de document utilise un dictionnaire d’horodatage de document.	ISO 32000-2	§12.8.5
Les entrées DSS et les horodatages de document prennent en charge les signatures à long terme.	ETSI EN 319 142-2	§5.5
Le gestionnaire de signature prend en charge les entrées DSS et les horodatages de document.	ETSI EN 319 142-2	§6.3.3.3
Un jeton d’horodatage porte un genTime UTC qui est l’instant où il a été créé.	RFC 3161	§2.4.2
OCSP indique good, revoked ou unknown, borné par thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2	,

Toutes les clauses sont paraphrasées. NextPDF ne reproduit pas le texte normatif ; consulte les normes publiées pour la formulation qui fait autorité. NextPDF ne formule aucune revendication de certification PAdES. Les structures décrites ici sont alignées sur les niveaux B-LT et B-LTA tels que 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 ETSI EN 319 142-1 se situe hors de l’ensemble de preuves cité, de sorte que cette page énonce la structure produite et la frontière Pro/Enterprise, et non un niveau de conformité certifié. La preuve ETSI citée est EN 319 142-2 ; les ancres ISO et RFC portent les revendications à long terme et d’horodatage, exactement comme le fait la référence de signature du Core.

Verrou d’édition

NextPDF Core produit les niveaux de base PAdES B-B et B-T : le Core livre le signataire CMS logiciel ainsi que le chemin d’horodatage RFC 3161, de sorte qu’une signature B-T (horodatée) est une capacité du Core et ne nécessite pas Enterprise. NextPDF Pro produit également B-B et B-T : Pro compose la pile RFC 3161 du Core pour ajouter l’attribut non signé signature-time-stamp sur la valeur de signature (PadesBtTimestamper, vérifié par fixture). Les niveaux B-LT et B-LTA — le producteur de DSS, VRI et d’horodatage de document — sont une capacité Enterprise et ne sont pas produits par le Core ni par Pro. Cela correspond au tableau des paliers publié sur la page de sécurité Pro : B-B et B-T sont produits par le Core et Pro, et B-LT et B-LTA par Enterprise uniquement. Le producteur B-T est structurel — il compose le signature-time-stamp RFC 3161 selon les preuves citées RFC 3161 / RFC 5652 / ETSI EN 319 122-1 ; ce n’est pas une revendication de conformité certifiée ETSI EN 319 142-1 ni une revendication qualifiée eIDAS. Dans un déploiement Pro uniquement, demander B-LT ou B-LTA échoue de manière sûre avec un message qui nomme le composant Enterprise manquant, car SignatureLevel::isAvailableInEnvironment() renvoie faux lorsque le producteur à long terme Enterprise est absent.

Niveau PAdES	Ajoute	Édition du producteur
B-B	Signature CMS avec attributs signés	Core, Pro, Enterprise
B-T	RFC 3161 signature-time-stamp sur la valeur de signature (structurel ; non qualifié eIDAS)	Core, Pro, Enterprise
B-LT	Document Security Store avec matériel de validation	Enterprise (`nextpdf/enterprise`) uniquement
B-LTA	Horodatages de document pour la validité archivistique	Enterprise (`nextpdf/enterprise`) uniquement

Voici la matrice canonique niveau→palier : B-B est la base produite par chaque édition ; B-T (horodaté) est également produit par le Core et Pro (Pro compose la pile RFC 3161 du Core) ; B-LT et B-LTA sont réservés à Enterprise. Le producteur B-T est structurel — ce n’est pas une revendication de conformité certifiée ETSI EN 319 142-1 ni une revendication qualifiée eIDAS.

Indicateur de fonctionnalité de licence

Le producteur à long terme fait partie de l’édition Enterprise (license_feature_flag: enterprise). Il se résout à l’exécution via le contrat du Core ; l’API publique ne change pas lors de la mise à niveau de Pro vers Enterprise.

Contrat de comportement

Le Core et Pro produisent tous deux B-B et B-T (B-T ajoute le signature-time-stamp RFC 3161 ; Pro compose la pile RFC 3161 du Core). B-LT et B-LTA sont une frontière Enterprise ; une demande de ces niveaux sans nextpdf/enterprise échoue de manière sûre avec une erreur nommée.
Le producteur écrit un 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.
Par défaut, l’application en échec sûr de la révocation 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.

Statut de l’analyse NDA

Cette page publique décrit uniquement le comportement du producteur observable de l’extérieur. Elle ne contient aucun chemin d’espace de noms interne, aucun nom de classe ou de trait interne, aucun nom de fichier de runbook et aucun préfixe de ticket interne. Les types concrets du producteur à long terme Enterprise ne sont référencés qu’à travers le contrat public du Core (LtvManagerInterface, SignatureLevel). Les détails internes de l’assemblage du DSS et de la boucle d’archivage figurent dans la référence approfondie protégée, sous NDA.

Repli sur le Core

Dans un déploiement Core uniquement, le signataire logiciel produit PAdES B-B et B-T avec une clé locale ou une clé fournie via le contrat de stratégie de signature du Core. Le Core livre le chemin d’horodatage RFC 3161, de sorte que B-T est accessible sans aucun paquet premium. Le Core n’a aucun producteur de DSS, VRI ni d’horodatage de document ; demander B-LT ou B-LTA échoue de manière sûre avec une erreur nommée. Voir Sécurité / Signature (Core).

Repli sur Pro

Dans un déploiement Pro uniquement, le chemin de signature pris en charge couvre la base Pro B-B et le niveau Pro B-T (Pro compose la pile RFC 3161 du Core pour ajouter l’attribut non signé signature-time-stamp), ainsi que ses stratégies de signature distantes et cloud-KMS. Pro ne produit aucun DSS, VRI ni horodatage de document. Une configuration qui demande B-LT ou B-LTA dans un déploiement Pro uniquement échoue de manière sûre avec un message qui nomme le composant Enterprise manquant. Voir Sécurité Pro pour la surface de signature Pro.

Note sur la frontière Enterprise

Le producteur de DSS, VRI et d’horodatage de document est décrit uniquement au niveau du comportement. La logique interne qui ordonne l’assemblage du DSS, les détails internes de génération des clés VRI par signature, et les détails internes d’ordonnancement de la boucle d’archivage sont hors du périmètre de la surface publique et ne sont pas reproduits ici.

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 lui-même 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 est responsable de la sélection et de l’accessibilité de la TSA, de l’accès aux répondeurs de révocation ou du matériel pré-collecté, de la politique réseau et de l’exécution de la boucle d’archivage avant l’expiration de chaque certificat d’horodatage.

Frontière de conformité légale

Cette page est marquée export_control_class: legal-review-required. Elle concerne la signature cryptographique et la validation à long terme. Une validation juridique est requise avant que l’indicateur publish ne soit défini. 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. Consulte tes propres conseillers conformité et juridiques pour tes obligations réglementaires.

Voir aussi

Sécurité / Signature (Core) — CMS, RFC 3161, validation de chemin RFC 5280, OCSP/CRL.
Sécurité Pro — la base B-B et la frontière Enterprise.
Archive : DSS, VRI, santé LTV — archivage à long terme et santé LTV.
Vérification de signature — le côté vérification : vérification cryptographique CMS / horodatage, TSA-at-genTime, et validation de la chaîne d’archivage.
Correspondance des bases PAdES — B-B, B-T, B-LT, B-LTA selon les éditions.
PAdES · DSS · VRI · LTV — termes du glossaire.

Signature : PAdES B-LT / B-LTA, DSS, horodatages de document