Le certificat expirait en 9999. Son lien au document pouvait rester non vérifié.

Résumé

• signedDocumentBinding restreint le certificat à une entrée de signature précise. La révision 02 indique néanmoins qu’une signature peut être cryptographiquement valide sans que ce lien soit contrôlé. Il faut donc conserver séparément le verdict de signature et la comparaison de dataTbsHash.
• Le certificat atteste aussi que l’AC a créé la clé pour une opération, ne l’a utilisée qu’une fois et l’a détruite. L’extension n’observe pas cette procédure. L’absence d’expiration et de révocation déplace l’autorité vers la politique de certification, l’audit de création et la conservation future de la confiance dans l’AC.

Le validateur voit un notAfter fixé au 31 décembre 9999, une extension noRevAvail, une signature correcte et un condensat de document dans le certificat. Il peut pourtant rendre son verdict sans avoir comparé le document courant à ce condensat.

Le certificat paraît fermer le cycle de vie. En réalité, il ouvre plusieurs questions d’autorité.

La révision 02 de One Signature Certificates définit un certificat émis au moment de la signature pour une clé nouvellement créée. La clé produit une seule signature, puis doit être détruite immédiatement. Le certificat vise un contenu déterminé, n’a normalement pas d’expiration utile et ne dépend pas d’un service de révocation. L’objectif est de simplifier la validation de longue durée en évitant une clé d’utilisateur durable et l’accumulation de statuts de révocation.

Il s’agit d’un Internet-Draft actif du groupe LAMPS, dans le flux IETF, destiné au statut Proposed Standard. La révision 02 date du 1er juillet 2026 et expire le 2 janvier 2027. Datatracker affiche WG Document et I-D Exists. Ce n’est pas un RFC, ni une preuve qu’une AC émet déjà ces certificats, qu’une clé a été détruite ou qu’un logiciel vérifie correctement le lien.

Le certificat décrit un périmètre et affirme une procédure

L’extension signedDocumentBinding contient dataTbsHash, hashAlg et, éventuellement, bindingType. Elle permet de recalculer le condensat d’une entrée de signature déterminée. C’est un objet technique précis : un algorithme, une règle de sélection des octets et une valeur attendue.

La présence de l’extension porte aussi une affirmation plus large. L’AC déclare que la clé privée a été générée exclusivement pour le document lié et détruite après la signature. Le projet demande que la politique de certification expose la procédure et l’assurance de destruction.

Une comparaison de hash et une attestation de procédure ne sont pas interchangeables. Les octets du certificat ne peuvent voir ni une copie HSM, ni une sauvegarde, ni un retry concurrent, ni un dump mémoire. Ils ne démontrent pas que la clé n’a signé qu’une fois. Ils authentifient ce que l’AC affirme avoir fait.

Le reçu d’émission doit donc garder la version de la CP/CPS, l’identité de la requête, le hash avant transformation, le type de lien, le hash des octets exacts, la création de clé, l’autorisation unique, la sortie de signature, la commande de destruction et son observation indépendante. Le certificat reste une pièce de cette chaîne, pas la chaîne entière.

La réussite de la signature ne vaut pas réussite du lien

La section sécurité ne laisse pas cette ambiguïté implicite : vérifier signedDocumentBinding n’est pas nécessaire pour obtenir une validation cryptographique réussie. Une application peut recevoir true de sa bibliothèque tout en ignorant le périmètre documentaire du certificat.

Cette séparation crée un risque de substitution. Si une clé supposée unique a servi une seconde fois, la seconde signature peut être mathématiquement correcte. Si le validateur ne compare pas le document au dataTbsHash, il ne détecte pas que le certificat avait été émis pour une autre entrée.

L’interface opérationnelle doit produire deux résultats. Le premier décrit la signature, son algorithme, la clé et les octets vérifiés. Le second décrit la présence du binding, son type, les octets reconstruits, le condensat recalculé et la comparaison. « Non contrôlé » est un état autonome ; il ne doit jamais devenir « conforme » par héritage du premier résultat.

Le projet emploie SHOULD pour le contrôle du lien. Une organisation peut adopter une règle plus stricte : toute signature qui prétend utiliser ce profil échoue si le binding est absent, inconnu ou non vérifié. Cette règle doit couvrir les clients, les services tiers et la revalidation des archives, pas seulement le chemin interactif principal.

Le type de lien définit le document cryptographique

Lorsque bindingType est absent, le mode par défaut prend l’entrée exacte de l’algorithme de signature : SignedInfo pour XML, SignedAttributes en DER pour CMS, ou la structure équivalente.

Cette règle devient circulaire si l’entrée signée contient le certificat, ou un hash de ce certificat, alors que le certificat contient lui-même dataTbsHash. Le projet interdit le mode par défaut dans ce cas et fournit des règles spécialisées.

Pour CAdES, le calcul porte sur SignerInfo après retrait de SigningCertificate et SigningCertificateV2. Pour XAdES, il retire les références vers SignedProperties du SignedInfo canonique, tout en préservant les autres caractères et espaces. Pour JWS et COSE, il ne lie que le payload, en excluant les en-têtes protégés et non protégés.

Ainsi, un payload JWS lié correctement ne dit rien, à lui seul, sur alg, l’identifiant de clé ou la référence au certificat. Ces champs restent soumis à la validation JWS et à la politique locale. Inversement, deux implémentations qui affichent le même nom de binding peuvent diverger sur la canonicalisation ou l’exclusion des octets.

Le registre demandé à l’IANA doit exiger une procédure déterministe et une explication des dépendances circulaires. Le reçu doit aller plus loin : identifier la spécification, la version d’implémentation et le hash de la séquence reconstruite.

L’absence de révocation concentre le risque au moment de l’émission

Le projet recommande 99991231235959Z pour signaler l’absence de fin définie et id-ce-noRevAvail pour annoncer qu’aucun mécanisme de révocation n’existe. RFC 9608 normalise ce second signal ; il ne certifie pas que l’absence de révocation est saine.

Le raisonnement repose sur le best-signature-time. Si la clé a réellement été créée, utilisée une fois et détruite, un événement de révocation ultérieur n’affecte pas la validité historique de cette signature. La fenêtre d’exposition est beaucoup plus petite que celle d’une clé réutilisée pendant des années.

Mais une compromission antérieure ou contemporaine reste possible. Il faut savoir si la clé était neuve, si l’infrastructure en possédait une copie, si la destruction a couvert toutes les répliques et si la politique a été appliquée. Un faible nombre de révocations observées n’est pas une preuve de ces contrôles.

Le validateur doit aussi distinguer trois situations : absence de révocation prévue par un profil reconnu ; service de statut temporairement inaccessible ; extension inconnue ou mal formée. Les réunir sous « aucun problème de révocation » supprime précisément l’information que noRevAvail devait apporter.

L’AC devient aussi une autorité temporelle

Une validation à long terme s’appuie généralement sur le moment le plus ancien où l’existence de la signature est prouvée. RFC 3161 propose un horodatage émis par une autorité dédiée. Ici, le certificat est créé avec la signature ; le projet considère donc l’heure d’émission comme l’heure de signature, l’AC jouant un rôle analogue à l’autorité d’horodatage.

Cette économie de preuve agrandit le mandat de l’AC. Elle atteste simultanément l’identité, la clé publique, le contenu lié, l’heure de l’acte, la création d’une clé fraîche et sa destruction. Toute horloge, file de reprise ou transaction partielle devient pertinente.

Le dossier devrait préciser la source du best-signature-time : émission du certificat, jeton RFC 3161, Signature Validation Token, preuve d’archive ou combinaison. Il faut conserver la source d’horloge, la transaction et la politique. Une date X.509 bien encodée ne devient pas, par sa syntaxe, un témoin indépendant.

L’année 9999 ne prolonge pas automatiquement la confiance dans l’AC

Le projet reconnaît que la validation reste limitée par la possibilité de faire confiance à l’AC. Il suppose une validation initiale pendant la validité du certificat de l’AC. Pour une revalidation future, il évoque un trust anchor local, une certification croisée ou le renouvellement des certificats d’AC dans un dépôt.

La construction de cette confiance au-delà de la validité de l’AC reste hors périmètre. Le notAfter extrême retire donc une échéance au certificat final ; il ne rend pas la chaîne, les algorithmes, les politiques, les dépôts et les logiciels immortels.

Un contrat de conservation doit nommer qui garde les octets originaux, la chaîne, la CP/CPS, les preuves de temps, les résultats de validation et l’historique des ancres. Il doit prévoir le retrait d’un algorithme ou d’une AC, ainsi qu’un mécanisme de correction des décisions applicatives malgré l’absence de révocation du certificat final.

Un lien correct ne prouve ni mandat ni résultat

Même contrôlé, signedDocumentBinding prouve une relation limitée entre certificat, règle de sélection et entrée de signature. Il ne prouve pas que le signataire a compris l’acte, détenait le mandat, a vu la représentation finale ou que l’effet extérieur s’est produit.

Une clé éphémère ne crée pas seule la non-répudiation. L’identité, le consentement, le mandat, l’intégrité de l’affichage, la politique, la livraison, l’archive et le résultat métier conservent leurs propres autorités.

La chaîne de décision doit rester typée : syntaxe du certificat ; chemin de confiance ; signature ; lien documentaire ; procédure de l’AC ; cycle de la clé ; temps fiable ; identité et autorisation ; décision de l’application ; conservation ; effet extérieur. Le profil réduit une partie de l’état. Il ne transforme pas tous ces états en un seul verdict.