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 : ce qui est vérifié, ce qui est rejeté en mode 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 PAdES B-LT / B-LTA.

Installation

composer require nextpdf/enterprise:^3

Vue d’ensemble conceptuelle

La vérification repose sur des preuves et fonctionne en mode fail-closed : un contrôle qui ne peut pas être établi positivement ne produit pas de résultat positif. Les éléments ci-dessous s’agrègent en un résultat unique 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 sont analysés strictement, que le certificat du signataire est résolu, 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 si 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 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 qu’ils ne peuvent pas diverger dans l’analyse de la liaison de certificat.

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 mode 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 mode 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 `sha*WithRSAEncryption` OID	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

Surface d’API

Le côté vérification s’utilise 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 — 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, tu dois examiner 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.

Cas limites & pièges

Algorithme non pris en charge ≠ non concluant. RSASSA-PSS, EdDSA et SHA-3 sont rejetés en mode 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. Aucun aller-retour réseau n’est effectué pendant la vérification — 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 d’accepter un élément 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-les 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. Les attaques par ajout-après-horodatage sont déjouées par la règle de couverture EOF conjuguée à l’ancrage de confiance, et non par une 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

Verrou d’édition

Ce côté vérification est une capacité Enterprise et est livré dans le paquet nextpdf/enterprise. NextPDF Core détecte la présence d’une signature et produit des signatures B-B / B-T ; il ne fournit pas ce côté vérification cryptographique. Obtiens une licence.

Indicateur de fonctionnalité de licence

Le côté vérification est verrouillé par l’édition Enterprise (license_feature_flag: enterprise). Il est résolu via les contrats Core et Pki ; l’API publique ne change pas lors d’une mise à niveau d’édition.

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é.

État de l’analyse NDA

Cette page publique décrit uniquement le comportement du côté vérification observable depuis l’extérieur. Elle nomme le moteur public, les contrats Pki / ancres de confiance, et la méthode validateArchivalTimestampChain() via la surface prise en charge. Les détails internes concrets DER, CMS, du processeur de politiques et du validateur de chemin se trouvent dans la référence approfondie verrouillée sous NDA.

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

Cette page est marquée export_control_class: legal-review-required ; elle concerne la vérification cryptographique. Une validation juridique est requise avant que l’indicateur publish ne soit défini. 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.
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.

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