Valider correctement une signature

Spec: RFC 5280, §6 Spec: RFC 6960 Spec: RFC 5652 Evidence: Test-backed

En bref

« La signature est valide » signifie généralement qu’une seule chose a été vérifiée : le calcul est cohérent. Une validation correcte vérifie au moins cinq éléments indépendants ; n’importe lequel d’entre eux peut échouer et rendre une coche verte dénuée de sens. Cette page présente l’ensemble des contrôles et explique pourquoi une réponse partielle est dangereuse.

Pourquoi c’est important

Un simple booléen est le résultat le plus dangereux dans ce domaine. Il incite à traiter « valide » comme « digne de confiance », alors que « valide » pourrait seulement signifier que les octets n’ont pas été altérés et qu’ils ont été signés avec une clé issue d’un certificat qui a expiré il y a trois ans, qui a été révoqué le mois dernier, et qui ne se rattache à aucune autorité que tu reconnais. Chacun de ces points est un contrôle distinct. Un logiciel qui ne renvoie qu’un booléen a décidé en silence quels contrôles comptaient, et il a décidé à ta place. Dans un cadre réglementé ou contractuel, « l’outil a dit valide » n’est pas une défense si l’outil n’a vérifié que la propriété la moins coûteuse à vérifier.

En résumé

Une validation complète répond à cinq questions distinctes. Elles sont indépendantes : en réussir une ne dit rien des autres :

Intégrité — les octets signés produisent-ils toujours l’empreinte que la signature couvre ? (Recalcule l’empreinte de la plage d’octets ; compare.)
Authenticité — la signature cryptographique se vérifie-t-elle avec la clé publique du certificat de signature, sur les attributs signés ?
Chemin de certification — ce certificat se rattache-t-il à une ancre de confiance que tu as choisie, chaque maillon étant valide ?
Temps — le certificat était-il dans sa fenêtre de validité au moment pertinent, et ce moment est-il de confiance plutôt qu’auto-déclaré ?
Révocation — le certificat n’était-il pas révoqué à ce moment-là, selon une preuve (OCSP/CRL) que tu peux réellement obtenir ou qui est incorporée ?

Un « valide » qui ne s’appuie pas sur les cinq contrôles est une réponse incomplète qui ressemble à une réponse complète.

L’approche de NextPDF

La position de NextPDF est que chaque question est distincte et que chacune doit recevoir une réponse explicite. Aucune question n’est réduite à un unique drapeau optimiste, ni ignorée en silence parce qu’un contrôle était gênant. Les tests l’imposent. C’est pourquoi cette page est marquée comme adossée à des tests plutôt qu’à une norme : le comportement est maintenu par la suite de tests, et pas seulement argumenté à partir d’une clause.

L’intégrité et l’authenticité sont testées de bout en bout. Un certificat connu signe une véritable structure d’attributs signés, et la suite de tests vérifie la signature avec la clé publique correspondante, sur plusieurs vecteurs temporels. Ainsi, un changement qui casse la structure canonique casse le test. La validation du chemin de certification est maintenue par des tests qui altèrent délibérément un octet de la signature et vérifient que le résultat n’est pas valide, avec une raison structurée : pas une exception lancée puis perdue, mais un échec explicitement enregistré. La vérification du jeton d’horodatage est décomposée en étapes discrètes — décodage, informations du signataire, attributs signés, empreinte du message, liaison au certificat, usage de la clé, signature, instant de production — et chaque étape est testée individuellement, si bien que « l’horodatage est vérifié » signifie que chaque étape l’a été. L’échec non bloquant de la révocation (un répondeur injoignable) est distingué, dans le code comme dans les tests, d’un « révoqué » définitif. Les deux ne sont jamais confondus dans une même réponse.

Integrity Recompute the byte-range digest and compare it to the value the signature covers.
Authenticity Verify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
Certificate path Build and validate the chain to a trust anchor you chose ; every link’s signature, validity, and constraints must hold.
Time Confirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
Revocation Confirm the certificate was not revoked at that time, using obtainable or embedded OCSP/CRL evidence.

Les cinq questions indépendantes auxquelles une validation correcte de signature PDF répond, dans l'ordre. Chacune est distincte : réussir l'une ne dit rien des autres, et en omettre une rend le résultat global incomplet.

Ce que disent les preuves

Evidence: Test-backed Le comportement est ancré par des tests, et ces tests mettent en œuvre ce que les normes exigent.

L’intégrité relève de Spec: ISO 32000-2, §12.8.1  : l’empreinte est recalculée sur la plage d’octets et comparée à la valeur stockée, et toute différence signifie que la signature est invalide. L’authenticité sur les attributs signés est couverte par un test d’intégration qui signe un véritable ensemble d’attributs signés et le vérifie avec la clé publique correspondante sur plusieurs vecteurs temporels. Le chemin de certification relève de Spec: RFC 5280, §6.1 : les chemins valides partent d’une ancre de confiance, et Spec: RFC 5280, §6.2 énonce que cet algorithme définit les conditions minimales pour qu’un chemin soit valide — un test unitaire de validateur de chemin vérifie qu’une signature altérée donne valid = false, avec une raison explicite, jamais une acceptation silencieuse.

L’ordre des contrôles de révocation relève de Spec: RFC 6960, §3.2  : avant d’accepter une réponse de révocation signée comme valide, un client DOIT confirmer que la signature de la réponse elle-même est valide et que le signataire est actuellement autorisé — et Spec: RFC 6960, §4.2.2.2 définit cette autorisation comme une délégation id-kp-OCSPSigning émise directement par l’AC en question. Ainsi, une réponse de révocation qui n’a pas elle-même été validée par rapport à un signataire autorisé et vérifiable est dénuée de sens. Le contrôle de liaison au certificat relève de Spec: RFC 5035, §5.4.2  : si l’empreinte du certificat dans l’attribut signé signing-certificate-v2 ne correspond pas au certificat utilisé pour vérifier la signature, la signature doit être considérée comme invalide. Cela ferme la faille de substitution, où une signature se vérifie avec un certificat choisi par l’attaquant. Le jeton d’horodatage lui-même est vérifié à la manière de Spec: RFC 5652 en tant qu’objet CMS, étape par étape, chaque étape étant testée individuellement.

Exemple pratique

La partie instructive n’est pas un appel d’API. Ce sont les questions auxquelles tu dois pouvoir répondre avant d’agir sur un résultat. Considère cela comme la liste de contrôle qu’une revue te demandera de justifier.

<?php

declare(strict_types=1);

// A correct validation produces a structured outcome, not one boolean.
// Before you trust a signature, you must be able to answer ALL of these:
//
//   integrity   : Does the byte-range digest still match? (tamper check)
//   authenticity: Does the signature verify over the SIGNED ATTRIBUTES,
//                  not just the content?
//   path        : Does the certificate chain to a trust anchor YOU chose,
//                  with every link valid at the relevant time?
//   time        : Is the relevant time TRUSTED (a timestamp), or merely the
//                  signer's self-asserted clock?
//   revocation  : Was the certificate not revoked at that time, by evidence
//                  you obtained or that the document embedded?
//
// "valid: true" without an answer to every line above is an incomplete
// result. A path-validation outcome carries a `valid` flag AND a structured
// `reasons` list precisely so a failure says WHY — never a bare false.

Si la réponse à une seule ligne est « je ne sais pas », le statut honnête n’est pas « valide ». C’est « pas encore déterminé » — et traiter les deux comme équivalents est l’erreur que cette page existe pour prévenir.

Idée fausse répandue

Le piège consiste à assimiler « cryptographiquement valide » à « digne de confiance ». L’intégrité et l’authenticité réunies ne prouvent que ces octets ont été signés par le détenteur de cette clé. Elles ne disent rien sur le fait que le certificat de la clé était de confiance, en cours de validité ou non révoqué. Un document signé avec un certificat auto-généré peut être « cryptographiquement valide » et ne rien valoir. Le piège inverse consiste à traiter un contrôle de révocation indéterminé (répondeur hors ligne) comme une réussite — ou comme un échec. Ce n’est ni l’un ni l’autre. C’est inconnu, et un validateur correct le signale comme inconnu plutôt que de deviner dans un sens ou dans l’autre. Une coche verte qui masque les contrôles réellement exécutés parmi les cinq n’est pas un résultat de validation. C’est une décision que quelqu’un d’autre a prise à ta place.

Limites et périmètre

NextPDF effectue et teste les contrôles structurels et cryptographiques. Il ne choisit pas tes ancres de confiance et ne garantit pas la politique qui s’appuie dessus. Le choix des certificats auxquels tu accordes ta confiance est une décision de déploiement que le moteur ne peut pas prendre. Une chaîne qui se valide jusqu’à une ancre à laquelle tu n’aurais pas dû faire confiance reste une validation sur laquelle tu ne peux pas t’appuyer. La preuve de révocation ne peut être vérifiée que si elle peut être obtenue ou si elle est incorporée. Un répondeur hors ligne donne « indéterminé », et transformer cela en un verdict est un choix de politique, pas un choix du moteur. Cette page décrit l’ensemble des contrôles, pas leur suffisance juridique. Qu’une signature validée ait un effet juridique particulier dépend du certificat, du signataire, de la juridiction et de l’obligation. La façon dont la preuve incorporée maintient ces contrôles vérifiables dans le temps est traitée dans Validation à long terme ; le mécanisme de plage d’octets derrière le contrôle d’intégrité figure dans Comment les signatures s’insèrent dans un PDF.

Disponibilité de la surface de validation par palier :

Signature validation checks — edition availability
Edition	Availability
Core	Intégrité et authenticité sur les attributs signés, plus la validation du chemin de certification RFC 5280 §6 par rapport à une ancre de confiance fournie.
Pro	Ajoute la vérification du jeton d’horodatage RFC 3161 — la question du temps de confiance, décomposée en étapes vérifiées indépendamment.
Enterprise	Ajoute l’évaluation de la révocation (OCSP/CRL) et la validation par rapport au matériel long terme incorporé, les résultats indéterminés étant distingués des résultats définitifs.

Documentation associée

Validation à long terme — comment la preuve incorporée maintient les contrôles de temps et de révocation vérifiables des années plus tard.
Comment les signatures s’insèrent dans un PDF — le mécanisme de plage d’octets que le contrôle d’intégrité recalcule.
Horodatages et temps de confiance — ce qui permet de répondre à la question du « temps » avec autre chose que l’horloge du signataire.

Glossaire

Contrôle d’intégrité — recalculer l’empreinte de la plage d’octets et la comparer à la valeur que la signature couvre.
Contrôle d’authenticité — vérifier la signature cryptographique avec la clé publique du certificat de signature, sur les attributs signés.
Attributs signés — les attributs CMS authentifiés (content-type, message-digest, signing-time, signing-certificate-v2) sur lesquels la signature est réellement calculée.
Validation du chemin de certification — construire et vérifier la chaîne depuis le certificat de signature jusqu’à une ancre de confiance choisie (RFC 5280 §6).
Ancre de confiance — une autorité de certification à laquelle tu as décidé de faire confiance ; la racine d’un chemin acceptable.
Contrôle de révocation — déterminer si un certificat a été révoqué au moment pertinent, via OCSP ou une CRL.
Indéterminé — un résultat de révocation qui n’est ni « bon » ni « révoqué » parce que la preuve n’a pas pu être obtenue ; ni une réussite, ni un échec.