Vérification de signature : AdES / PAdES, côté vérification cryptographique

En bref

NextPDF Enterprise vérifie les signatures numériques sur le plan cryptographique. Le côté vérification lit un CMS SignedData ou un jeton d’horodatage RFC 3161 depuis le PDF, recalcule les condensats, contrôle les signatures, lie chaque signature à son certificat de signature et valide la chaîne de certificats — y compris le traitement des politiques de certificat — par rapport à un magasin d’ancres de confiance fourni par l’appelant. Cette page décrit le comportement. Elle énonce ce qui est vérifié, ce qui est rejeté en fail-closed, les algorithmes pris en charge et l’emplacement de la frontière de confiance.

Cela se distingue de Validation, qui exécute des contrôles de politique structurels en lecture seule et n’effectue délibérément aucune cryptographie. C’est aussi le pendant, côté vérification, du producteur de signatures, qui écrit des structures PDF Advanced Electronic Signatures (PAdES) B-LT / B-LTA.

Disponibilité et licence

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

Installation

composer require nextpdf/enterprise:^3

Vue d’ensemble conceptuelle

La vérification repose sur des preuves et fonctionne en fail-closed : un contrôle qui ne peut pas être établi positivement ne produit pas de résultat positif. Les éléments ci-dessous se combinent en un unique résultat porté par un ValidationReport.

Vérification cryptographique du CMS / du jeton d’horodatage. Une pile DER autonome, stricte et à longueur définie analyse le CMS SignedData et le jeton d’horodatage RFC 3161. Un jeton n’est accepté que lorsqu’il porte exactement un SignerInfo, que ses attributs signés s’analysent strictement, que le certificat du signataire se résout, que l’attribut message-digest correspond au condensat recalculé, que la liaison de certificat de signature obligatoire (ESS signing-certificate-v2) est satisfaite et que la signature SignerInfo se vérifie sur les attributs signés ré-étiquetés. La règle de correspondance des condensats suit le modèle de vérification RFC 5652 §5.6 / §5.4 : le destinataire recalcule le condensat de message du contenu, et la signature n’est valide que lorsque cette valeur est égale à l’attribut signé messageDigest. Un vérificateur ne fait jamais confiance à un condensat fourni par le producteur.

Validation du certificat TSA à genTime. Le genTime de l’horodatage est l’instant UTC où le jeton a été créé (RFC 3161 §2.4.2). Le certificat de signature TSA est validé à cet instant, et non à « maintenant » : son utilisation de clé étendue doit être un unique id-kp-timeStamping critique (RFC 3161 §2.3), et sa fenêtre de validité, sa chaîne, la provenance de son ancre de confiance et sa révocation sont toutes évaluées par rapport à genTime. Une chaîne structurellement bien formée mais qui n’atteint pas une ancre de confiance configurée ne peut jamais étayer un résultat positif.

Signatures de document PAdES basiques détachées. Un extracteur concret effectue une véritable vérification Advanced Electronic Signatures (AdES) / PAdES basique pour une signature de document détachée : le condensat de message est recalculé sur la plage d’octets signée puis comparé, la signature est vérifiée et la liaison de certificat de signature est obligatoire. Cela remplace le précédent repli purement structurel. Le vérificateur d’horodatage et l’extracteur de signature de document partagent un seul validateur ESS d’émetteur et de numéro de série, de sorte que l’analyse de la liaison de certificat ne peut pas diverger.

Chaîne de couverture DocTimeStamp d’archivage. validateArchivalTimestampChain() valide une chaîne de jetons DocTimeStamp de confiance sur les plages d’octets du PDF en tant que preuve d’archivage B-LTA. L’empreinte de chaque jeton est liée aux octets ByteRange réels qu’il couvre, la chaîne suit l’ordre strict ETSI, la chaîne TSA de chaque jeton est ancrée à la confiance et la chaîne doit couvrir le fichier jusqu’à son marqueur de fin de fichier. Elle n’atteint un résultat entièrement réussi que pour une chaîne complète, ancrée à la confiance et couvrant jusqu’à l’EOF.

Traitement des politiques de certificat (RFC 5280 §6.1.4). La validation de chemin applique un traitement complet des politiques de certificat : un arbre de politiques structuré en nœuds, le mappage de politiques avec le repli anyPolicy et l’intégration de policyConstraints / inhibitAnyPolicy, le tout adossé à un lecteur DER d’extension de politique en fail-closed. Les variables d’état du traitement de chemin explicit_policy et inhibit_anyPolicy (RFC 5280 §6.1.2) déterminent si un arbre de politiques valide non vide est requis ; l’étape de clôture intersecte l’arbre de politiques valide avec l’ensemble de politiques initial de l’utilisateur (RFC 5280 §6.1.4). Sans politiques requises et avec anyPolicy accepté, le traitement est sans contrainte — c’est la valeur par défaut, inchangée par rapport au comportement antérieur.

Algorithmes pris en charge

Le côté vérification accepte l’ensemble d’algorithmes ci-dessous et échoue en fail-closed sur tout ce qui n’en fait pas partie : un algorithme non pris en charge donne une vérification rejetée, jamais une acceptation silencieuse.

Famille	Pris en charge	Notes
RSA (PKCS#1 v1.5)	rsaEncryption avec SHA-2, et les OID sha*WithRSAEncryption	Accepté
ECDSA	courbes P-256, P-384, P-521	Accepté
RSASSA-PSS	—	Non pris en charge → fail-closed
EdDSA	—	Non pris en charge → fail-closed
Condensats SHA-3	—	Non pris en charge → fail-closed
SHA-1	—	Faible : une signature basique qui se vérifie sous SHA-1 est rétrogradée en échec de contraintes cryptographiques, et non en acceptation

Pourquoi cela fonctionne ainsi

Le côté vérification est fail-closed par conception. Il ne renvoie un résultat positif que pour un élément qu’il peut établir positivement ; tout le reste se traduit par un résultat indéterminé ou un échec. Cela écarte la tentation par défaut de faire confiance à un jeton bien formé et d’apparence plausible. La confiance est toujours relative à un magasin d’ancres fourni par l’appelant, de sorte que le moteur n’affirme jamais une confiance qu’on ne lui a pas donnée. Le certificat d’un horodatage est jugé à son genTime, et non à « maintenant », car c’est à ce moment que le jeton a réellement été créé. Les algorithmes non pris en charge sont rejetés d’emblée, jamais différés, de sorte qu’un schéma faible ne peut pas se faufiler sous la forme d’une acceptation non concluante.

Contexte de conception : Valider correctement une signature.

Surface d’API

Tu utilises le côté vérification via le moteur public et les contrats Core / Pki. Les classes de stratégie concrètes sont internes.

Type	Nature	Rôle
AdESValidationEngine	classe	Le point d’entrée du côté vérification : validation de signature et de chaîne d’archivage.
AdESValidationEngine::validateArchivalTimestampChain()	méthode	Valider une chaîne de couverture DocTimeStamp de confiance sur les plages d’octets du PDF.
ValidationReport	résultat	Le résultat structuré : le statut global plus les constats par contrôle.
PathValidatorInterface	interface (NextPDF\…\Pki)	Le SPI de validation de chemin de certification dont dépend le moteur.
PathValidationOptions	objet valeur	Contrôles de traitement des politiques : requireExplicitPolicy, inhibitAnyPolicy, inhibitPolicyMapping, maxPolicyFanout.
TrustAnchorStoreInterface	interface	L’ensemble d’ancres de confiance fourni par l’appelant par rapport auquel la chaîne est évaluée.

La méthode de chaîne d’archivage a cette signature :

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

Elle n’atteint un résultat entièrement réussi que lorsque la chaîne DocTimeStamp est entièrement vérifiée, ancrée à la confiance et couvre le fichier jusqu’à son marqueur EOF.

CertificateChainValidator::validate() prend un ensemble de politiques initial (l’ensemble de politiques initial de l’utilisateur RFC 5280). La valeur par défaut est anyPolicy, qui est sans contrainte, de sorte qu’une chaîne ordinaire n’est pas affectée. Passe un ensemble explicite, ou définis requireExplicitPolicy, pour exiger un arbre de politiques valide non vide.

Exemple de code — Démarrage rapide

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

Exemple de code — Production

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

Changements de comportement & notes de mise à niveau

Le côté vérification est passé d’une acceptation structurelle / temporelle à une vérification cryptographique complète. Si tu t’appuies sur l’ancien comportement, plus permissif, examine ces changements.

• Fail-closed sur un horodatage reconnaissable mais invérifiable. Un DocTimeStamp ou un jeton d’archivage qui passait auparavant sur des bases structurelles et temporelles requiert désormais une vérification cryptographique complète : signature, message-digest et liaison de certificat de signature. Un jeton qui ne se vérifie pas ne produit plus une preuve d’existence positive ; il se traduit par un résultat indéterminé ou un échec.
• Les signatures basiques SHA-1 sont rétrogradées, non acceptées. Une signature de document basique qui se vérifie mais utilise SHA-1 est signalée comme un échec des contraintes cryptographiques plutôt que comme une acceptation complète.
• Le traitement des politiques de certificat RFC 5280 §6.1.4 est appliqué. Une chaîne dont explicit_policy atteint zéro avec un arbre de politiques valide vide échoue désormais — y compris lorsqu’un policyConstraints interne à la chaîne requireExplicitPolicy l’impose. Les chaînes par défaut, sans contrainte (aucune politique requise, anyPolicy accepté), ne sont pas affectées.
• Changement de signature du constructeur (rupture de compatibilité). AdESValidationEngine::__construct() type désormais son paramètre $chainValidator comme le SPI Pki\PathValidatorInterface, défini de façon paresseuse par défaut à Pki\CertificateChainValidator::withDefaults(). C’était auparavant le Ltv\CertificateChainValidator concret. Un appelant qui injectait le validateur LTV concret doit injecter à la place l’implémentation du SPI Pki. Le validateur Pki enveloppe le même moteur de chemin structurel et ajoute les contraintes de nom et le traitement des politiques ; c’est une opération neutre pour des entrées par défaut conformes.
• Liaison stricte de l’empreinte d’horodatage de signature (rupture de compatibilité). Un horodatage de signature PAdES B-T est désormais lié, pendant la validation, à la signature qu’il couvre : l’empreinte de message du jeton doit être égale au hachage de la valeur de signature SignerInfo (RFC 3161 Appendix A ; ETSI EN 319 122-1 §5.3). La règle est appliquée aussi bien dans le chemin de validation avec temps que dans celui de validation avec données à long terme. Un attribut d’horodatage de signature manquant ou dupliqué est un échec de format ; une empreinte qui ne se lie pas, ou un jeton qui ne se vérifie pas, donne un résultat indéterminé / d’ordre d’horodatage ; un algorithme d’empreinte SHA-1 ou non reconnu donne un résultat indéterminé / de contraintes cryptographiques. Dans le chemin à long terme, le certificat TSA du jeton lié est en outre évalué à son genTime ; avec le contrôle de confiance par défaut sans magasin, cela se résout en Indeterminate tant qu’un magasin d’ancres de confiance n’est pas configuré — une valeur par défaut fail-closed délibérée. Un document dont l’horodatage de signature a été produit par une version de NextPDF antérieure à ce correctif a lié une entrée différente et ne peut pas satisfaire le contrôle ; re-signe et re-horodate pour rétablir un temps B-T positif.

Cas limites & pièges

• Algorithme non pris en charge ≠ non concluant. RSASSA-PSS, EdDSA et SHA-3 sont rejetés en fail-closed, et non différés. Si tes signataires les utilisent, ce côté vérification ne renverra pas de résultat positif pour eux.
• La confiance est relative à l’ancre. La vérification est toujours relative au magasin d’ancres de confiance que tu fournis. Un ensemble d’ancres vide ou erroné produit un résultat non fiable, quelle que soit la justesse cryptographique.
• genTime, pas maintenant. Le certificat TSA est jugé au genTime du jeton. Un certificat TSA qui a depuis expiré peut toujours étayer un jeton créé alors qu’il était valide ; un certificat non encore valide à genTime ne le peut pas.
• Couverture EOF. La chaîne d’archivage doit couvrir le document jusqu’à son marqueur EOF. Un horodatage qui ne couvre qu’un préfixe du fichier n’établit pas une couverture du document entier.
• Non-prouvé-révoqué n’est pas Good. Un verdict Valid exige un statut non révoqué de façon concluante. Si OCSP et CRL reviennent tous deux Unknown ou Unavailable, même une signature cryptographiquement saine, à chaîne valide et ancrée à la confiance, se résout en Indeterminate. Fournis du matériel OCSP/CRL Good intégré pour le certificat du signataire afin d’atteindre Valid.

Performance

La vérification s’effectue en cours de processus sur les octets PDF fournis et le matériel de validation intégré ; le coût croît avec la longueur de la chaîne et le nombre d’horodatages. La vérification n’effectue aucun aller-retour réseau. Le matériel de révocation et de confiance provient de ce que l’appelant fournit ou de ce qui est intégré dans le document. La vérification est déterministe : les mêmes entrées et les mêmes ancres de confiance produisent le même rapport.

Notes de sécurité

• Le fail-closed est la valeur par défaut. Chaque étape d’acceptation refuse le matériel qu’elle ne peut pas vérifier positivement. Cela empêche un document d’annoncer une validité que le moteur n’a jamais établie.
• L’ajout-après-horodatage est déjoué par la couverture EOF. Parce que l’empreinte de chaque horodatage d’archivage est liée aux octets ByteRange réels et que la chaîne doit atteindre l’EOF, le contenu ajouté après un horodatage n’est pas couvert par celui-ci et ne bénéficie pas de son poids probatoire.
• Traite l’entrée comme hostile. Les octets PDF, le CMS intégré et les jetons d’horodatage provenant de sources non fiables sont analysés par un lecteur DER strict à longueur définie qui rejette les encodages malformés ou à longueur indéfinie.

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

La vérification s’effectue en cours de processus et localement, sans E/S réseau. Les certificats et les signatures portent l’identité du sujet ; applique tes propres contrôles de rétention et de minimisation aux rapports et à toute donnée de certificat extraite.

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

Les constats portent des identifiants de contrôle et des statuts. Certains diagnostics peuvent renvoyer des noms de sujet de certificat ou des numéros de série ; nettoie ou caviarde ces champs avant de transmettre les journaux à des destinataires partagés.

Limites de portée

Énonce ces limites dans la sortie destinée à l’utilisateur afin qu’un résultat positif ne soit pas surinterprété.

• validateArchivalTimestampChain() prouve la couverture de plage d’octets, non l’accessibilité xref. Elle établit qu’une chaîne d’horodatage de confiance couvre cryptographiquement les plages d’octets du document jusqu’à l’EOF. Elle n’effectue pas d’analyse d’accessibilité d’objets au niveau xref ou startxref ; cela est hors de portée par conception. La règle de couverture EOF, conjuguée à l’ancrage de confiance, déjoue les attaques par ajout-après-horodatage, et non l’analyse du graphe d’objets.
• Hors de portée par conception. Les Evidence Records (RFC 4998 / RFC 6283) ; la vérification des jetons d’horodatage RSASSA-PSS, EdDSA ou SHA-3 ; l’intégration des listes de confiance (TSL) et des TSA qualifiées ; et la récupération en ligne de la révocation TSA ne sont pas fournies par ce côté vérification. La révocation est évaluée à partir du matériel déjà disponible pour le vérificateur.

Conformité

Comportement	Référence	Statut
Valeur de signature / jeton d’horodatage stocké encodé en DER dans /Contents	ISO 32000-2 §12.8.1	Analysé et vérifié
Dictionnaire d’horodatage de document	ISO 32000-2 §12.8.5	Lu pour la chaîne d’archivage
Le destinataire recalcule le condensat du contenu ; il doit être égal à l’attribut messageDigest	RFC 5652 §5.6 / §5.4	Appliqué
Le certificat TSA porte un unique id-kp-timeStamping EKU critique	RFC 3161 §2.3	Vérifié à genTime
genTime est l’instant de création UTC	RFC 3161 §2.4.2	Utilisé comme instant de validation
Variables d’état du traitement des politiques (explicit_policy, inhibit_anyPolicy)	RFC 5280 §6.1.2	Traité
La clôture intersecte l’arbre de politiques valide avec l’ensemble de politiques initial de l’utilisateur	RFC 5280 §6.1.4	Appliqué
Entrées DSS et horodatages de document pour les signatures à long terme	ETSI EN 319 142-2 §5.5	Validé en tant que preuve d’archivage

Toutes les clauses sont paraphrasées. NextPDF ne reproduit pas de texte normatif ; consulte les normes publiées pour le libellé faisant autorité. NextPDF ne fait aucune revendication de certification AdES / PAdES. Le côté vérification implémente les contrôles cryptographiques décrits par les spécifications citées ; ce n’est pas un service de validation certifié et il ne produit aucune attestation tierce.

Comportement en mode FIPS

Lorsque le profil FIPS Enterprise est actif, la contrainte s’applique aux algorithmes de condensat et de signature que le vérificateur accepte. La logique de vérification — recalcul de condensat, contrôles de signature, liaison de certificat et validation de chemin — est inchangée.

Modèle de menace

Actif	Adversaire	Risque	Mesure d’atténuation
Jeton d’horodatage	Jeton falsifié ou altéré	Une fausse preuve d’existence	Vérification cryptographique complète ; fail-closed sur tout ce qui est invérifiable
Certificat TSA	Émetteur non fiable	Une confiance apparente que le vérificateur ne devrait pas affirmer	Chaîne validée jusqu’à une ancre fournie par l’appelant à genTime ; une chaîne non fiable ne passe jamais
Octets du document	Ajout-après-horodatage	Le contenu gagne le poids d’un horodatage sans couverture	Empreinte liée aux octets ByteRange réels + règle de couverture EOF
Algorithme faible	Rétrogradation vers SHA-1 / schéma non pris en charge	Une signature faible lue comme valide	SHA-1 rétrogradé ; RSASSA-PSS / EdDSA / SHA-3 en fail-closed

Contrat de comportement

• Un jeton CMS ou d’horodatage n’est accepté qu’avec exactement un SignerInfo, des attributs signés strictement analysés, un certificat de signataire résolu, un message-digest correspondant, la liaison de certificat de signature obligatoire, et une signature SignerInfo qui se vérifie.
• Le certificat TSA est validé au genTime du jeton : un unique id-kp-timeStamping EKU critique, sa fenêtre de validité, une chaîne ancrée à la confiance et la révocation.
• Un verdict Valid exige en outre un statut non révoqué de façon concluante : au moins un Good faisant autorité (une réponse OCSP vérifiée-good, ou une CRL fraîche plaçant le numéro de série hors d’une liste non expirée). Un statut simplement non-prouvé-révoqué, où OCSP et CRL sont tous deux Unknown ou Unavailable, se résout en Indeterminate, jamais Valid (ETSI EN 319 102-1 : statut de révocation indisponible → INDETERMINATE). Parce que le chemin de repli CRL n’atteste que la fraîcheur de la liste et non la révocation par numéro de série, une chaîne uniquement CRL sans OCSP Good est couramment Indeterminate.
• validateArchivalTimestampChain() n’atteint un résultat entièrement réussi que pour une chaîne DocTimeStamp complète, ancrée à la confiance et couvrant jusqu’à l’EOF ; elle prouve la couverture de plage d’octets, non l’accessibilité xref.
• Le traitement des politiques de certificat suit RFC 5280 §6.1.4 ; les chaînes par défaut, sans contrainte, ne sont pas affectées.
• Les algorithmes pris en charge sont RSA (PKCS#1 v1.5 avec SHA-2) et ECDSA (P-256/384/521) ; RSASSA-PSS, EdDSA et SHA-3 échouent en fail-closed ; SHA-1 est rétrogradé.

Frontière de publication

Cette page documente uniquement le comportement observable depuis l’extérieur et la surface d’API publique prise en charge. Les chemins d’espaces de noms internes, les classes utilitaires, les tables de mécanismes, les noms de fichiers de runbook et les préfixes de tickets sont hors de portée.

Repli sur le cœur

NextPDF Core détecte la présence d’une signature et produit des signatures B-B / B-T, mais il ne vérifie pas cryptographiquement les jetons CMS ou d’horodatage, ne valide pas de chaîne d’archivage et n’exécute pas le traitement des politiques RFC 5280 §6.1.4. Un déploiement Core uniquement n’a aucun côté vérification équivalent ; voir Sécurité / Signature (Core).

Repli sur Pro

NextPDF Pro ajoute des stratégies de signature et la gestion des factures électroniques, mais ne fournit pas ce côté vérification cryptographique ; la validation de chaîne d’archivage et le traitement des politiques de certificat sont livrés uniquement dans nextpdf/enterprise.

Note sur la frontière Enterprise

Le côté vérification est décrit au niveau du comportement. La pile DER stricte, le parseur CMS, le processeur de politiques et les détails internes du validateur de chemin sont hors de portée pour la surface publique et ne sont pas reproduits ici.

Frontière de déploiement

La vérification dépend du magasin d’ancres de confiance et de tout matériel de révocation que l’appelant fournit ou qui est intégré dans le document. NextPDF Enterprise évalue ce matériel ; il n’exploite ni liste de confiance, ni TSA, ni service de révocation. L’opérateur est responsable de la sélection des ancres et de la fraîcheur du matériel de révocation intégré.

Frontière de conformité juridique

elle concerne la vérification cryptographique. Un résultat de vérification positif est une affirmation cryptographique sur les signatures et les horodatages du document. Ce n’est pas un avis juridique, une détermination de qualification eIDAS, ni une certification. NextPDF ne fait aucune revendication de certification AdES / PAdES. Consulte tes propres conseillers en conformité et juridiques pour tes obligations réglementaires.

Voir aussi

• Signature : producteur PAdES B-LT / B-LTA — le côté producteur.
• Signature — Référence approfondie — DSS, VRI, horodatages de document et application de la révocation en profondeur.
• Validation — contrôles de politique structurels en cours de processus (sans cryptographie).
• Archive : DSS, VRI, santé LTV — archivage à long terme et santé LTV.
• Sécurité / Signature (Core) — CMS, RFC 3161, validation de chemin RFC 5280, OCSP/CRL.
• Mappage de référence PAdES — B-B, B-T, B-LT, B-LTA selon les éditions.
• PAdES · DSS · LTV — termes du glossaire.