Validation à long terme

Spec: ETSI EN 319 142-1Spec: RFC 6960Spec: ISO 32000-2, §12.8.4

En bref

Une signature que tu vérifies aujourd’hui repose sur des faits qui ne durent pas : un certificat qui expire, des serveurs de révocation qui deviennent inaccessibles, et des algorithmes de hachage qui s’affaiblissent. La validation à long terme consigne les preuves dans le document tant qu’elles sont encore accessibles. La signature peut alors être contrôlée des années plus tard sans avoir à interroger qui que ce soit.

Pourquoi c’est important

La propriété dangereuse d’une signature numérique, c’est qu’elle peut cesser silencieusement d’être vérifiable tout en paraissant inchangée. Rien ne change dans le fichier. L’autorité de certification cesse de répondre aux questions sur un certificat expiré depuis longtemps. Un vérificateur qui avait besoin de cette réponse ne peut plus l’obtenir. Un contrat qui était incontestablement valide le jour de sa signature devient « impossible à déterminer » une décennie plus tard. Une décennie plus tard, c’est précisément le moment où un litige est le plus probable et où les enjeux sont les plus élevés. Si ton obligation de conservation se mesure en années, une signature sans validation à long terme est un risque qui n’apparaît que plus tard.

En résumé

La validité d’une signature dépend de faits externes sensibles au temps : la fenêtre de validité du certificat et l’état de révocation fourni par un serveur.
Ces faits deviennent impossibles à obtenir après l’expiration du certificat — les autorités ne sont pas tenues de répondre éternellement.
La validation à long terme capture les preuves au moment de la signature — certificats, réponses OCSP, CRL — et les intègre dans le Document Security Store (DSS) du document.
Un horodatage de document prouve ensuite que les preuves elles-mêmes existaient et étaient valides à cet instant, et il peut être renouvelé avant que sa propre protection ne s’affaiblisse.
Résultat : le document porte sa propre preuve. La vérification ne dépend plus de la présence continue d’un serveur.

L’approche de NextPDF

Le principe est « rassembler la preuve tant que tu le peux encore, puis la sceller ». Lorsque NextPDF produit une signature à long terme, il collecte la chaîne de certificats et les réponses de révocation qui prouvent que le certificat de signature était valable au moment de la signature. Il les inscrit dans le DSS sous forme de valeurs intégrées plutôt que de liens. Il ajoute ensuite un horodatage de document sur l’ensemble. Les valeurs intégrées sont l’essentiel. Un lien vers un serveur de révocation est exactement la dépendance que la validation à long terme a pour but de supprimer.

Les couches à long terme sont écrites sous forme de révisions distinctes du document, ajoutées sans perturber la plage d’octets de la signature d’origine. La première signature continue de se vérifier. Le matériel à long terme est ajouté autour d’elle, non pas dedans. Lorsque la protection de l’horodatage de document lui-même vieillit, le niveau d’archivage permet de superposer un autre horodatage par-dessus. Le résultat est une chaîne où chaque horodatage se porte garant de tout ce qui se trouve en dessous.

SignerLa signature et ses attributs signés sont écrits (B-B).
Capturer les preuvesLa chaîne de certificats, les réponses OCSP et les CRL prouvant que le certificat était valide au moment de la signature sont rassemblées.
Intégrer dans le DSSLes preuves sont écrites dans le document sous forme de valeurs intégrées, et non de liens (B-LT).
Sceller avec un horodatage de documentUn horodatage prouve que les preuves intégrées existaient et étaient valides à cet instant (B-LTA).
Renouveler avant l’affaiblissementUn autre horodatage est superposé avant que la protection du précédent ne vieillisse, prolongeant la vérifiabilité.

Comment la validation à long terme maintient une signature vérifiable au fil du temps : la signature est créée, les preuves sont capturées tant qu'elles sont encore accessibles, les preuves sont scellées par un horodatage de document, et le sceau est renouvelé avant qu'il ne s'affaiblisse.

Exemple pratique

Le niveau que tu choisis est la décision à long terme. L’API rend l’exigence explicite avant que tu ne t’engages.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// B-LT embeds validation material; B-LTA adds the renewable seal.
$level = SignatureLevel::PAdES_B_LTA;

$level->requiresDss();                // true  → certificates + revocation embedded
$level->requiresDocumentTimestamp();  // true  → a document timestamp seals the DSS

// The high-level seam produces the level end to end: it embeds the DSS
// dictionary and appends the DocTimeStamp revision in one call.
$document
    ->setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)
    ->save();

// The engine produces this only if the deployment can supply what it needs
// (a TSA, and revocation data reachable at signing time). It fails with an
// actionable error rather than embedding nothing and reporting success.

Le raccord de haut niveau montré ci-dessus — setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save() — est désormais câblé de bout en bout ; les versions antérieures exposaient l’énumération de niveau mais pas le raccord qui le produit. Ce qu’il écrit, c’est la structure : le dictionnaire DSS et la révision DocTimeStamp décrite par Spec: ISO 32000-2, §12.8. Cette structure ne fait pas l’objet de tests de conformité de profil, et le raccord n’affirme rien quant à la conformité ETSI ou à la validité juridique. Les niveaux B-LT et B-LTA nécessitent le paquet Enterprise, qui s’installe par-dessus Pro ; sans lui, le raccord échoue en mode fermé plutôt que de produire un résultat partiel. Un document chiffré échoue lui aussi en mode fermé pour B-LT et B-LTA ; le DSS et l’horodatage de document ne sont pas écrits par-dessus un contenu chiffré, car cela les écrirait de manière incorrecte.

Ce choix ne peut pas être mis en œuvre après coup à moindre coût. Les preuves de révocation doivent être capturées au moment de la signature, tant que les réponses existent encore. Décider « nous ajouterons la validation à long terme plus tard » revient généralement à décider « nous n’aurons pas les preuves au moment où nous en aurons besoin ».

Idée fausse courante

L’idée fausse, c’est que « la validation à long terme rend une signature valide pour toujours ». Elle ne rend rien valide. Elle préserve la capacité de contrôler une validité qui a été établie au moment de la signature. Si le certificat était déjà révoqué lorsque le document a été signé, intégrer ce fait ne sauve pas la signature. Au contraire, cela documente l’échec de façon permanente. La validation à long terme est un mécanisme de préservation de preuve, non de création de preuve. Une seconde idée fausse consiste à croire que B-LTA se règle « une fois pour toutes ». L’horodatage d’archivage protège à l’aide d’algorithmes qui vieillissent eux-mêmes. Sans renouvellement, un fichier B-LTA finit par hériter de la même fragilité à laquelle il était censé échapper.

Limites et frontières

NextPDF rassemble et intègre les preuves et écrit les horodatages. Il n’est pas maître de la véracité des preuves ni de leur calendrier de renouvellement. Les réponses de révocation ne valent que par l’autorité qui les a émises et par le moment où elles ont été récupérées. La connectivité vers cette autorité au moment de la signature relève de la responsabilité du déploiement. Le moteur ne peut pas inventer une réponse de révocation qu’il n’a pas pu obtenir. Le renouvellement d’archivage est un processus opérationnel. Le moteur peut ajouter un autre horodatage, mais il ne peut pas décider quand ta politique de conservation l’exige. Savoir si les données intégrées seront jugées suffisantes plus tard est une question de validateur et de politique, traitée dans Valider correctement une signature. Cette page n’affirme pas la recevabilité juridique, qui dépend de la juridiction, du signataire et du certificat.

Disponibilité de la validation à long terme par palier :

Validation à long terme (intégration du DSS et la boucle d'horodatage d'archivage) — edition availability
Edition	Availability
Core	Not in this edition
Pro	PAdES B-T — un horodatage de confiance sur la valeur de signature — est disponible, mais le matériel de validation intégré (DSS) ne fait pas partie de B-T.
Enterprise	PAdES B-LT et B-LTA : valeurs de certificat et de révocation intégrées dans le DSS, l’horodatage de document qui les scelle, et la boucle d’archivage renouvelable.

Documents liés

Profils de référence PAdES — où se situent B-LT et B-LTA dans la progression des niveaux et ce que chacun ajoute.
Horodatages et temps de confiance — l’horodatage de document qui scelle les preuves intégrées.
Valider correctement une signature — comment un validateur utilise le matériel intégré, et pourquoi « valide » seul est incomplet.
Workflow des accords signés — le workflow de bout en bout où le matériel de validation à long terme est appliqué en pratique.

Glossaire

Validation à long terme (LTV) — intégrer les preuves nécessaires pour vérifier une signature afin que la vérification ne dépende pas de services externes par la suite.
Document Security Store (DSS) — la structure PDF qui contient les certificats intégrés et les données de révocation pour la validation à long terme.
Réponse OCSP — une déclaration signée de l’état de révocation d’un certificat à un instant donné (Online Certificate Status Protocol, RFC 6960).
CRL — Certificate Revocation List ; une liste signée de certificats révoqués.
Horodatage de document — un horodatage RFC 3161 appliqué à l’ensemble du document, prouvant que les preuves intégrées existaient et étaient valides à ce moment-là.
Boucle d’archivage — ajouter à plusieurs reprises un nouvel horodatage de document avant que la protection du précédent ne s’affaiblisse, prolongeant ainsi la vérifiabilité.