Résumé

  • La RFC 3741 réduit la sensibilité des signatures portant sur des fragments XML extraits aux déclarations de noms de leurs ancêtres : elle sérialise surtout les préfixes effectivement visibles dans les noms d’éléments ou d’attributs.
  • Elle ne supprime pas toute dépendance au contexte : des attributs xml: hérités ou des préfixes présents uniquement dans des valeurs peuvent changer l’interprétation après réencapsulation.

L’enveloppe ne devrait pas réécrire la signature du contenu

Imaginons qu’un protocole signe un élément XML à l’intérieur d’un message volumineux. Une passerelle retire l’enveloppe externe ; un autre service insère ensuite le même élément dans un nouveau message. Avec Canonical XML inclusif, des déclarations de noms et certains attributs xml: hérités peuvent entrer dans la séquence d’octets canonique même si le fragment ne les utilise pas. Une modification de l’enveloppe suffit alors à changer l’entrée du condensat et à faire échouer la signature d’un fragment pourtant intact.

Publiée en mars 2004, la RFC 3741 répond à ce problème précis. Elle définit une méthode de sérialisation exclusive pour un ensemble de nœuds XPath. Plutôt que d’importer la plupart du contexte de noms des ancêtres, elle émet une liaison lorsque son préfixe est visiblement utilisé dans un nom d’élément ou d’attribut. Le paramètre facultatif InclusiveNamespaces PrefixList permet de désigner des préfixes à traiter de manière inclusive malgré cette règle. L’objectif est qu’un sous-document signé puisse être extrait puis inséré dans une autre enveloppe sans que chaque emballage de transport fasse partie de sa forme canonique.

Il s’agit d’un choix de frontière, non d’une promesse d’autonomie sémantique. Les limites figurent dans la RFC elle-même. La RFC 3075 porte sur les données effectivement couvertes par XML Signature ; la RFC 3076 décrit la canonicalisation d’un ensemble de nœuds déjà obtenu après analyse. La RFC 3741 traite de la question plus étroite du contexte à conserver quand le sous-ensemble choisi est déplacé.

« Visible » est utile, mais le critère reste étroit

La règle s’appuie sur les noms XML. Si un élément ou un attribut emploie le préfixe n1, la liaison de n1 doit apparaître pour le sérialiser. Un préfixe déclaré par un ancêtre mais absent de ces noms peut être omis. Cette économie est utile : une enveloppe SOAP ou protocolaire peut contenir des déclarations nécessaires à l’enveloppe, mais étrangères au contenu extrait. La canonicalisation exclusive peut alors produire les mêmes octets pour le contenu dans deux enveloppes différentes.

Le sens applicatif peut toutefois dépendre d’informations invisibles dans les noms du sous-ensemble. Une valeur d’attribut peut contenir une expression XPath dont les préfixes comptent. Une application peut aussi traiter une chaîne comme xsi:type="xsd:decimal" comme un QName, alors que XPath ne voit qu’une valeur textuelle. Si aucun nom d’élément ou d’attribut n’utilise visiblement xsd et que la liste inclusive ne le mentionne pas, la liaison peut disparaître. Le destinataire risque alors d’interpréter cette valeur autrement dans la nouvelle enveloppe.

La RFC indique trois moyens de gérer cette dépendance : rendre l’utilisation du préfixe visible dans la structure, garantir la même liaison dans tous les contextes d’interprétation, ou inscrire le préfixe dans InclusiveNamespaces PrefixList. Chacun exige une décision de conception. La liste ne détecte pas les sémantiques cachées ; l’application doit savoir quelles valeurs portent un QName ou une expression sensible aux espaces de noms.

Le contexte omis des octets peut toujours gouverner la lecture

La canonicalisation exclusive ne copie pas non plus les valeurs ancestrales xml:lang, xml:space ou xml:base vers les nœuds orphelins du sous-ensemble. Elles peuvent influer sur la langue, le traitement des espaces ou la résolution des références relatives. La RFC exige que l’application ajoute la valeur nécessaire dans le sous-ensemble, ou qu’une valeur équivalente soit garantie dans chaque contexte où il sera interprété.

Son avertissement sur le contexte cible est plus frappant. Les octets canoniques d’un fragment peuvent rester identiques après son déplacement sous un nouvel espace de noms par défaut. Pourtant, l’application réceptrice peut rattacher l’élément sans préfixe à un autre espace de noms, et donc le traiter comme un autre type d’objet. La signature est valide parce que les octets sélectionnés n’ont pas changé ; le sens attribué par l’application peut changer avec le contexte de destination.

La RFC 3741 ne définit ni l’extraction, ni l’insertion, ni la réparation des déclarations d’espaces de noms. Elle ne décide pas non plus si l’opération est autorisée. Le protocole doit préciser quel contexte accompagne le fragment et ce que le consommateur est censé en faire. L’intégrité cryptographique ne constitue qu’une étape de cette chaîne.

Une frontière de signature plus étroite accroît le travail d’intégration

La canonicalisation exclusive échange une dépendance accidentelle à l’enveloppe contre l’obligation explicite d’inventorier les dépendances sémantiques. Pour un fragment signé qui circule, l’examen ne doit pas s’arrêter à la vérification de signature. Il faut aussi demander si les préfixes, attributs xml:, valeurs de QName et références relatives gardent le même sens à destination. Sans contrat explicite, la stabilité de la signature peut être prise à tort pour une stabilité du sens.

Il s’agit du risque décrit par la spécification, pas de la preuve d’une attaque ou d’une panne particulière. La RFC 3741 est informative : elle établit l’objectif et les limites de l’algorithme, mais pas la fréquence de son déploiement ni une défaillance d’un service nommé. Sa leçon est plus ciblée : retirer du contexte des octets signés améliore la portabilité, mais seule l’application peut savoir quel contexte omis continue d’en gouverner l’interprétation.

Sources