Workflow des accords signés

Spec: ETSI EN 319 142-2, §5.1 Spec: ISO 32000-2:2020, §12.8 Evidence: Mixed evidence

En un coup d’œil

Un accord signé, ce n’est pas « un PDF auquel on a ajouté une signature ». C’est un document préparé pour que la signature protège les bons octets. Il est signé à un niveau qui correspond à l’obligation. Il est conditionné pour rester vérifiable même après l’expiration du certificat de signature. Cette page déroule ce scénario, du document vierge au contrat à longue durée de vie. Elle indique clairement quelles étapes le moteur câble aujourd’hui et lesquelles il expose comme une surface gelée.

Pourquoi c’est important

Un contrat qui se vérifie le jour de sa signature mais échoue trois ans plus tard lors d’un litige est pire qu’une absence de signature, parce que quelqu’un s’y est fié. L’échec vient rarement de la cryptographie. Il s’agit le plus souvent d’un horodatage manquant ou d’une preuve de révocation absente, découverts bien après que le signataire est passé à autre chose.

Choisir l’obligation de signature dès le départ, et produire la preuve dont cette obligation a besoin au moment de la signature, fait toute la différence entre un accord qui tient et un accord qui se délite en silence. C’est une décision à prendre une seule fois, dans le flux de travail, plutôt qu’à redécouvrir à chaque litige.

La version courte

Préparer, puis signer. Une signature couvre exactement la plage d’octets sur laquelle elle a été calculée. Décide que le document est définitif — y compris toute révision ajoutée par la suite — avant de signer, pas après.
Choisis le niveau pour l’obligation, et non l’inverse. PAdES définit une progression : une signature de base, une signature horodatée, une signature avec du matériel de validation embarqué, et une signature ré-horodatée pour une validité d’archivage indéfinie (ETSI EN 319 142-2 §5.1).
La validité à long terme est une structure, pas une propriété. C’est un Document Security Store accompagné d’un horodatage de document, écrit dans le fichier (ISO 32000-2:2020 §12.8).
Sois précis sur la jointure. Le Document::setSignature() de haut niveau de NextPDF gèle l’API publique mais échoue vite plutôt que d’émettre un fichier non signé. Le chemin câblé est celui de l’orchestrateur de plus bas niveau. Cette page ne prétend pas le contraire.

Comment NextPDF l’aborde

NextPDF sépare la décision du mécanisme. La décision, c’est le niveau PAdES que l’obligation requiert. Le mécanisme, c’est la façon dont les octets sont signés et celle dont le matériel de validation est transporté. Traiter ces deux aspects comme un seul, c’est ainsi que les équipes se retrouvent avec une signature valide mais pas durable.

Le scénario comporte quatre étapes.

Prepare the document Compose the agreement and treat it as final. The signature will protect this exact byte range and nothing added outside it without a new revision.
Choose the obligation B-B proves who. B-T adds trusted time. B-LT embeds the material to validate later. B-LTA re-stamps for indefinite validity.
Sign A CMS signature is embedded in the signature dictionary over the byte range ; a timestamp is requested from a TSA if the level needs one.
Preserve For long-term levels, the Document Security Store and a document timestamp are written so the signature outlives its certificate.

Le scénario de l'accord signé de bout en bout : chaque étape ajoute une garantie, et le niveau que tu choisis à l'étape deux détermine la quantité de preuves que les étapes trois et quatre devront produire.

L’énumération des niveaux existe vraiment et elle encode fidèlement l’obligation. B-B prouve l’identité du signataire. B-T ajoute un horodatage de confiance. Le « quand » est posé aussi fermement que le « qui ». B-LT embarque les certificats et les réponses de révocation nécessaires pour valider la signature après l’expiration du certificat de signature. B-LTA ajoute des horodatages de document pour que la chaîne de confiance puisse être prolongée indéfiniment, en ré-horodatant avant que chaque certificat d’horodatage n’arrive à expiration. L’énumération sait quels niveaux exigent un horodatage et lesquels exigent du matériel de validation embarqué, de sorte que le moteur peut refuser une combinaison impossible plutôt que de produire un fichier « signé » trompeur.

Le point à dire franchement : Document::setSignature() existe pour que la surface de l’API publique soit gelée pour les consommateurs en aval, mais la jointure d’écriture qui le transforme en véritable révision signée n’est pas encore câblée. L’appeler puis appeler save() n’émet pas un PDF non signé en considérant la tâche terminée. Cela échoue vite avec un diagnostic bloquant qui nomme le chemin pris en charge. Échouer vite, plutôt que produire un artefact silencieusement erroné, tel est le choix de conception. Un contrat qui semble signé mais ne l’est pas est l’échec précis que cela évite. Le chemin câblé aujourd’hui est l’orchestrateur à deux phases de plus bas niveau, et les capacités d’archivage à long terme sont de niveau Premium.

Ce que dit la preuve

La progression est adossée à une norme. Evidence: Standard-backed Spec: ETSI EN 319 142-2, §5.1 décrit les niveaux PAdES bâtis sur les blocs de construction de l’EN 319 142-1, à partir d’une signature de base embarquée, puis au-delà. La structure à long terme est fixée par Spec: ISO 32000-2:2020, §12.8  : la validation à long terme repose sur un Document Security Store et un dictionnaire d’horodatage de document écrits dans le fichier.

Le modèle de niveaux est adossé au code. Evidence: Code-backed L’énumération SignatureLevel a les quatre cas PAdES (B-B, B-T, B-LT, B-LTA) avec des méthodes prédicats pour « requiert un horodatage », « requiert du matériel de validation embarqué » et « requiert des horodatages de document ». Le Document::setSignature() de haut niveau est câblé à une garde « échec rapide » qui déclenche un diagnostic bloquant et exploitable plutôt que d’émettre un document non signé — un comportement vérifiable, pas une affirmation.

Le comportement de maintenance à long terme est documenté au niveau capacité pour l’édition Premium : la surface d’archivage écrit le DSS et la VRI par signature, inspecte l’exhaustivité de l’archivage au moyen d’un contrôle de santé et ré-horodate avec un horodatage de document avant que le certificat d’horodatage n’expire. La documentation indique clairement que la décision finale revient toujours au vérificateur.

Exemple pratique

Ceci montre la décision — sélectionner l’obligation — en utilisant l’énumération réelle. Le chemin de signature câblé est celui de l’orchestrateur de plus bas niveau. L’appel de haut niveau n’est montré que pour rendre explicite le comportement « échec rapide ».

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

/**
 * Map a business obligation to a PAdES level.
 *
 * The obligation drives the level, not the reverse — choosing B-B for a
 * 10-year contract is a decision you do not want to make implicitly.
 */
function levelForObligation(string $obligation): SignatureLevel
{
    return match ($obligation) {
        // Internal sign-off, short retention, signer identity is enough.
        'internal_approval' => SignatureLevel::PAdES_B_B,

        // Counterparty agreement: prove the moment of signing.
        'counterparty_agreement' => SignatureLevel::PAdES_B_T,

        // Regulated contract that must verify after cert expiry.
        'regulated_contract' => SignatureLevel::PAdES_B_LT,

        // Long-lived legal record: indefinite, re-stampable validity.
        'long_term_legal_record' => SignatureLevel::PAdES_B_LTA,

        default => throw new \InvalidArgumentException(
            "Unknown obligation: {$obligation}",
        ),
    };
}

$level = levelForObligation('regulated_contract');

// The enum carries the obligation's implications with it.
$needsTsa     = $level->requiresTimestamp();         // true for B-T+
$needsDss     = $level->requiresDss();               // true for B-LT+
$needsArchive = $level->requiresDocumentTimestamp(); // true only for B-LTA

L’objet de niveau n’est pas une simple étiquette. Il porte ce que l’obligation implique, de sorte que le câblage en aval n’a pas à le redériver.

Idée fausse répandue

L’idée fausse récurrente est « la signature est valide, donc nous avons terminé. » La validité aujourd’hui est nécessaire mais pas suffisante. Une signature est calculée sur une plage d’octets. Tout ce qui est ajouté en dehors de cette plage dans une révision ultérieure n’est pas couvert par elle : c’est précisément pour cela que la préparation vient avant la signature. Et une signature qui se vérifie maintenant peut échouer plus tard, à l’expiration de son certificat, sauf si le matériel de validation a été embarqué au moment de la signature. « Valide » et « durable » sont des garanties différentes, et seule l’obligation te dit laquelle il te faut réellement.

Un piège connexe propre à ce moteur : supposer que le setSignature() de haut niveau produit un fichier signé aujourd’hui. Ce n’est pas le cas. Il échoue vite à dessein. Considère le diagnostic comme le contrat.

Limites et frontières

Document::setSignature() est une surface publique gelée, pas un signataire câblé. Il échoue vite avec un diagnostic bloquant. Il n’émet jamais un PDF non signé à la place d’un PDF signé. Le chemin câblé est l’orchestrateur à deux phases de plus bas niveau.
La maintenance de la validation à long terme (DSS/VRI, contrôle de santé, boucle d’horodatage d’archivage) est une capacité de niveau Premium. Le Core ne fournit pas la boucle d’archivage. Vois la frontière ci-dessous.
Une signature protège exactement sa plage d’octets. Les révisions ajoutées par la suite sont distinctes. Le moteur n’étend pas rétroactivement la couverture.
NextPDF produit et maintient les structures ; il ne tranche pas. Qu’une signature soit de confiance dépend des ancres de confiance et de la politique du vérificateur, qui sont en dehors du moteur.
B-LTA ne rend pas une signature éternelle à lui seul. Il ne permet une validité indéfinie que si la boucle de ré-horodatage s’exécute selon le calendrier prévu, avant l’expiration de chaque certificat d’horodatage.
Cette page décrit le comportement de la surface d’archivage Premium. Elle n’affirme aucune acceptation par un tribunal ou une autorité en particulier.

PAdES signing and long-term validity — edition availability
Edition	Availability
Core	Le Core expose l’énumération `SignatureLevel` et la surface gelée `Document::setSignature()` (échec rapide). L’orchestrateur câblé de plus bas niveau couvre la signature de base. La maintenance d’archivage à long terme n’est pas dans le Core.
Pro	La signature de base PAdES (B-B / B-T) via l’orchestrateur est disponible.
Enterprise	Ajoute B-LT / B-LTA, le Document Security Store et la maintenance de la VRI par signature, le contrôle de santé LTV et la boucle d’archivage par horodatage de document pour une validité indéfinie.

Documents liés

Profils de base PAdES — B-B, B-T, B-LT, B-LTA expliqués comme une progression, avec des repères pour choisir.
Validation à long terme — pourquoi une signature qui se vérifie aujourd’hui peut échouer dans dix ans, et comment la LTV embarque la preuve.
Le guide de décision d’intégration — quel paquet de l’écosystème convient à un flux de signature, y compris la jointure d’approbation humaine dans NextPDF Connect.

Glossaire

PAdES — PDF Advanced Electronic Signatures : la famille de profils ETSI définissant comment une signature électronique avancée est portée dans un PDF.
Plage d’octets — la portion contiguë d’octets du fichier sur laquelle une signature est calculée ; le contenu en dehors n’est pas protégé par cette signature.
Niveau de signature (B-B / B-T / B-LT / B-LTA) — la progression PAdES : qui a signé, quand, avec du matériel de validation embarqué, et ré-horodatable pour une validité d’archivage indéfinie.
TSA — Time-Stamping Authority (autorité d’horodatage) : un service RFC 3161 qui atteste qu’un état de document existait à un instant UTC donné.
DSS (Document Security Store) — le magasin embarqué dans le fichier, contenant les certificats, les réponses OCSP et les CRL nécessaires pour valider une signature après l’expiration de son certificat.
LTV (Long-Term Validation) — garder une signature vérifiable dans le temps en embarquant la preuve de validation et en la ré-horodatant.
Échec rapide — refuser de produire un artefact trompeur et déclencher à la place une erreur exploitable, plutôt que d’émettre un fichier silencieusement erroné.