Résumé

  • La RFC 3075 faisait signer la forme canonique de SignedInfo, dont chaque Reference engageait le condensat d’un objet après une chaîne ordonnée de transformations.
  • Une validation centrale réussie ne prouvait ni la couverture de tout l’arbre XML, ni l’identité institutionnelle de la clé, ni le contrôle de chaque membre d’un Manifest, ni la fidélité de l’écran présenté.

La difficulté historique n’était pas de placer une valeur cryptographique dans un élément XML. Elle consistait à rendre explicite le trajet qui fabriquait l’objet signé.

Une ressource pouvait se trouver dans la signature, l’envelopper ou vivre à une adresse extérieure. Une Reference pouvait la désigner, puis demander un décodage, une sélection XPath, une transformation XSLT ou une canonisation. Le condensat était calculé à la sortie de cette chaîne. Les références et leurs méthodes entraient dans SignedInfo, lui-même canonisé avant le calcul ou la vérification de SignatureValue.

Publiée en mars 2001 par le groupe XMLDSIG, la RFC 3075 rendait cette composition interopérable pour des données XML ou non XML. Mais elle refusait implicitement le raccourci « ce document est signé » tant que le mot document ne désignait pas exactement le résultat transformé.

Le résultat central réunissait deux vérifications

La validation des références reprenait chaque objet annoncé par SignedInfo, obtenait les données destinées au condensat, appliquait la méthode choisie et comparait le résultat à DigestValue. La validation de signature utilisait ensuite une clé pour vérifier SignatureValue sur la forme canonique de SignedInfo.

Un SignatureValue correct ne réparait pas un condensat faux. Des condensats exacts ne prouvaient pas que SignedInfo avait été authentifié. Lorsque les deux opérations réussissaient, le reçu reliait une clé à un ensemble précis de condensats et d’identifiants de traitement. Il ne s’étendait pas de lui-même aux nœuds voisins, aux ressources affichées plus tard ou à l’autorisation que l’application voulait accorder.

Cette architecture impose deux pièces de preuve pour toute enquête : les octets canoniques de SignedInfo réellement vérifiés et les octets exacts remis à chaque fonction de condensat après transformation. Un booléen de bibliothèque ne contient pas ces deux histoires.

La sélection n’était pas un détail de transport

XPath pouvait retrancher des champs ; XSLT pouvait produire une représentation nouvelle ; Base64 pouvait retrouver les octets cachés derrière des caractères ; la canonisation pouvait sérialiser un ensemble de nœuds. Une signature enveloppée devait même exclure sa propre valeur du calcul afin de ne pas dépendre d’elle-même.

Ces possibilités répondaient à de vrais besoins. Un formulaire pouvait protéger ses clauses fixes tout en gardant une zone modifiable. Un conteneur XML pouvait signer le binaire décodé plutôt que ses balises. La sélection devenait dangereuse seulement lorsque l’interface prétendait que le tout avait été protégé. Une information écartée par la transformation pouvait changer sans modifier le condensat. La signature restait valide pour l’objet choisi ; le commentaire qui l’accompagnait devenait abusif.

La RFC ajoutait une limite opérationnelle encore plus fine. La validation centrale ne confirmait pas forcément que le vérificateur venait d’obtenir la ressource et d’exécuter chaque étape déclarée. Une application pouvait accepter une copie déjà transformée dans son cache ; une autre imposer une récupération fraîche. L’égalité du condensat ne disait pas laquelle de ces politiques avait été suivie.

Canoniser rendait le calcul reproductible

Un analyseur XML normalise les fins de ligne et certaines valeurs, développe les entités et distribue les déclarations d’espace de noms sur l’arbre. DOM et SAX perdent aussi des choix de surface tels que l’ordre des attributs. Sans règle commune, le signataire et le vérificateur pouvaient traiter la même structure et produire des suites d’octets différentes.

La canonisation fixait une représentation physique reproductible. Elle ne démontrait pas qu’une feuille de style produisait le même message humain, qu’un schéma était digne de confiance, qu’un nom d’espace avait le sens supposé ou qu’un nœud exclu n’avait aucune importance. Canonical XML 1.1 conserva cette modestie : les équivalences propres à une application dépassaient la forme canonique générale.

Le rendu appartenait à la chaîne de preuve

La section de sécurité de la RFC 3075 demandait de rapprocher ce qui était signé de ce qui avait été présenté lorsque la signature exprimait un jugement. Signer littéralement une image d’écran était possible, mais peu maniable. L’autre solution consistait à protéger les données ainsi que les filtres, feuilles de style, profils clients et autres intrants capables d’en changer la présentation.

Le destinataire devait réciproquement agir sur la forme transformée et signée, non sur une version originale ou intermédiaire choisie par commodité. Une feuille de style externe non référencée pouvait modifier ce que l’utilisateur voyait sans casser la signature des données.

Cette recommandation ne transformait pas XML Signature en droit du consentement. La norme associait une clé à des octets référencés. Elle ne définissait pas normativement l’association de cette clé à une personne ou une institution, ni la portée sociale du contenu.

KeyInfo renseignait la clé, pas son autorité

L’élément facultatif KeyInfo pouvait contenir une clé, un certificat, un nom ou une méthode de récupération. L’application pouvait aussi le supprimer si elle connaissait déjà la clé par contexte. Dans la structure de base, il restait hors de SignedInfo. Pour le lier, le signataire pouvait créer une Reference supplémentaire.

Même lié, KeyInfo ne résolvait pas la confiance. Un certificat authentique pouvait être impropre à l’acte demandé ; un nom exact pouvait n’être qu’un index local. La RFC 2807 avait borné la mission du groupe : fournir la relation cryptographique entre contenu et clé, tout en laissant les assertions et la confiance extensibles aux applications.

Le Manifest n’était pas un reçu collectif automatique

Un Manifest regroupait des références pour lesquelles l’application voulait une politique plus souple. Si SignedInfo référençait ce Manifest, la validation centrale contrôlait le condensat de l’élément Manifest. En revanche, l’application décidait quels membres internes contrôler et comment réagir à une ressource inaccessible ou à un échec de condensat.

L’authenticité de la liste ne prouvait donc pas la réussite de chaque ligne. Il fallait conserver les résultats membre par membre. Présenter la bordure signée comme la preuve de tous ses objets revenait à attribuer au noyau une opération qu’il n’avait pas nécessairement accomplie.

Les successeurs ont réduit la liberté d’exécution

La RFC 3275 remplaça la RFC 3075 en mars 2002 après l’expérience d’interopérabilité et modifia plusieurs structures. XML Signature 1.1 et les bonnes pratiques du W3C ont ensuite recommandé d’authentifier SignedInfo avant d’exécuter des références risquées, d’établir séparément la confiance dans la clé, de limiter XPath, XSLT, RetrievalMethod, le nombre de transformations et les URI externes, puis de vérifier que les éléments utilisés par l’application sont bien protégés.

Ces textes ultérieurs ne prouvent aucune attaque contre un déploiement particulier de 2001. Ils confirment qu’une description de signature exécutable a besoin d’un profil de sécurité autour de la primitive cryptographique.

Les essais ultérieurs de Lu Heng sur la primauté du code en fonctionnement et les couches de réalité servent ici de lentilles déclarées. Ils séparent la syntaxe, les octets transformés, le résultat cryptographique, la confiance, le rendu et l’effet. Ils ne faisaient pas partie de la RFC. La leçon durable se trouve déjà dans sa frontière : la signature était forte précisément lorsqu’on refusait de lui faire dire plus que son objet.

Sources

Lu Heng n’a rédigé ni approuvé la RFC 3075, la RFC 3275 ou les recommandations du W3C. Ses essais sont des cadres analytiques ultérieurs explicitement signalés.