Résumé

  • Une ressource externe peut modifier l’infoset ou la validation alors que les octets du message n’ont pas changé ; sa provenance et sa version font donc partie de la preuve.
  • La bonne chaîne sépare réception, encodage, configuration du parseur, accès externes, validation, espaces de noms, portée de la signature, autorisation et résultat observé.

Le message avait été archivé. Son empreinte n’avait pas bougé. Pourtant, rejoué quelques semaines plus tard, il ne produisait plus le même objet applicatif.

La différence ne se trouvait pas dans le paquet. Le processeur XML avait consulté une dépendance extérieure : schéma, entité ou base d’URI. Entre les deux exécutions, cette dépendance avait changé. L’organisation possédait la preuve des octets, mais pas celle de l’interprétation.

Publié en janvier 2003 comme Best Current Practice 70, le RFC 3470 ne présente pas XML comme le choix naturel de tout protocole. Il énonce des règles pour ceux qui l’ont déjà choisi. Son enseignement le plus utile est une discipline de responsabilité : un message n’est pas seulement ce qui arrive, mais aussi ce que le logiciel va chercher et ce qu’il en fait.

Le paquet ne contient pas toute l’entrée

Un document bien formé respecte la syntaxe XML. Cette propriété est nécessaire : le RFC refuse l’interprétation partielle d’un document mal formé, car deux correspondants pourraient alors valider des fragments différents. L’échec doit être entier avant que l’état applicatif ne diverge.

Mais le succès du parseur ne décrit pas encore son environnement. Le processeur transforme une syntaxe concrète en XML Information Set. Il peut résoudre des entités, tenir compte d’une déclaration d’encodage, appliquer une base d’URI, charger un schéma et ajouter des valeurs par défaut. L’arbre observé par l’application peut donc dépendre d’entrées absentes de la capture réseau.

Le premier reçu doit préserver les octets, leur encodage, le type de média, le transport et l’heure. Le second doit identifier le parseur, sa version, sa configuration et sa politique d’accès externe. Sans ce couple, « même message » signifie seulement « même fichier conservé ».

Une validation datée n’est pas une vérité intemporelle

La validation répond à une question bornée : le document satisfait-il les contraintes du profil et de la version indiqués ? Elle ne prouve pas l’autorisation, la cohérence avec l’état courant ni l’exécution de l’ordre.

Le RFC 3470 rappelle que DTD, XML Schema et autres formalismes n’expriment pas les mêmes contraintes. Une partie des règles reste inévitablement dans la prose et dans le code. Dire « valide » sans nommer le schéma, sa version et son mode de résolution revient à omettre la moitié de la question.

Les attributs par défaut montrent le problème. Un validateur connaissant la déclaration peut présenter à l’application une valeur que le paquet ne portait pas. Un analyseur de trace dépourvu du schéma ne la voit pas. Les deux rapports divergent sans que l’un ait altéré la capture. C’est pourquoi le RFC déconseille ces valeurs implicites dans les protocoles.

Une dépendance distante ajoute le temps à cette ambiguïté. Si l’URI livre aujourd’hui un autre schéma, le même document peut changer de statut ou d’infoset. Une archive exploitable conserve donc le contenu exact de la dépendance, son empreinte et la règle qui l’a sélectionnée.

Résoudre une URI, c’est exercer un pouvoir réseau

Une référence externe ne se contente pas d’enrichir une structure. Elle autorise un composant à initier une requête depuis son propre emplacement. Un expéditeur extérieur peut ainsi provoquer un accès vers un service interne, révéler la topologie de résolution ou consommer des ressources.

Le RFC 3470 recommande d’éviter les déclarations d’entités dans les protocoles et d’interdire l’accès arbitraire aux ressources externes lors du traitement de données non fiables. Les cinq entités prédéfinies et les références numériques ne posent pas le même problème : elles ne donnent pas au document un nouveau canal de sortie.

La règle doit être positive et testable : accès désactivé, catalogue local immuable, liste autorisée ou objet embarqué. « Le parseur devrait être prudent » n’est ni une politique ni un reçu.

xml:base oblige aussi à nommer le point de départ. Une enveloppe, le transport et le document peuvent chacun proposer une base. Le protocole doit déterminer leur priorité. Sinon, une référence relative mène à plusieurs objets selon l’implémentation.

L’espace de noms n’est pas un serveur de règles

Les noms d’espaces XML ont la forme d’URI, mais ce sont d’abord des identifiants de vocabulaire. Ils ne doivent pas nécessairement être déréférencés. Le domaine qu’ils évoquent ne suffit pas non plus à authentifier l’auteur d’une opération.

La spécification applicative doit relier le nom au sens. Elle doit décider du sort des extensions inconnues : rejet, ignorance, conservation, transfert ou erreur « obligatoire à comprendre ». Un document peut être parfaitement bien formé et rester inexploitable parce que cette gouvernance n’a jamais été écrite.

Une subtilité syntaxique renforce le risque : l’espace de noms par défaut s’applique aux éléments non préfixés, pas aux attributs non préfixés. Lire l’attribut comme s’il appartenait automatiquement au vocabulaire de l’élément peut attribuer une autorité que le document n’a pas exprimée.

Les instructions de traitement et les commentaires ne doivent pas devenir des canaux normatifs cachés. Le RFC demande que le traitement ordinaire puisse les ignorer.

Canoniser ne fige pas le monde extérieur

Canonical XML, défini par le RFC 3076, produit une sérialisation reproductible d’un ensemble de nœuds. XML Signature, décrit par le RFC 3275, ajoute des références et des transformations. Ces outils réduisent certaines variations de représentation ; ils ne décident pas ce que l’application doit croire.

Une signature valide doit être accompagnée de sa portée exacte : nœuds référencés, transformations, algorithme de canonisation, clé et identité vérifiée. Si l’application lit ensuite un voisin non signé ou une valeur venue d’un schéma extérieur, la preuve cryptographique ne couvre pas cette décision.

Il faut également conserver l’entrée avant transformation. Deux systèmes qui comparent l’un des octets et l’autre l’infoset canonisé ne comparent pas le même objet, même si chacun publie une empreinte exacte.

La signature prouve au mieux l’intégrité et une identité dans son périmètre. Elle ne confère pas le droit d’effectuer l’opération et ne démontre pas que l’état a changé.

Le blanc visible peut être une donnée

Une équipe peut « nettoyer » un document en l’indentant. En XML, les caractères d’espacement appartiennent à l’information tant que le protocole ou le schéma ne définit pas une autre règle. La mise en forme peut donc altérer une valeur.

À l’inverse, l’ordre des attributs n’a pas de signification XML et certaines valeurs sont normalisées. Une implémentation qui donne du sens à cet ordre fabrique une contrainte privée. Le RFC préfère les mécanismes communs aux sous-ensembles ad hoc qui acceptent seulement la forme produite par un générateur maison.

Un protocole interopérable doit préciser espaces, contenu mixte, ordre des éléments, représentation des extensions et comportement d’erreur. Une convention éditoriale n’est pas un contrat de fil.

La conformité du document ne protège pas le parseur

XML n’apporte par lui-même ni confidentialité, ni intégrité, ni authentification, ni autorisation. Le code qui le traite reste exposé à des structures malicieuses, aux expansions, aux dépassements de ressources et aux défauts de mémoire.

Le reçu de sécurité comprend les limites de taille, profondeur, temps, mémoire, expansion et accès réseau. Il comprend aussi le comportement d’échec. Une grammaire correcte peut provoquer un coût interdit ; un document banal peut rencontrer une faille d’implémentation.

Le RFC 8996 actualise le contexte de transport en dépréciant TLS 1.0 et 1.1. Une version TLS moderne protège un canal selon sa configuration ; elle ne rend pas le contenu sémantiquement juste ni l’action autorisée.

Rejouer l’environnement, pas seulement le fichier

Une preuve complète commence par l’empreinte des octets et l’encodage. Elle nomme le parseur et sa configuration. Elle enregistre la bien-formation stricte et l’échec complet, puis chaque entité, base et ressource externe.

Viennent ensuite l’infoset obtenu, le profil de validation, les espaces de noms et les extensions. La canonisation et le jeu précis de références signées forment un autre reçu. L’identité cryptographique ne remplace pas les contrôles sémantiques et l’autorisation.

Enfin, il faut prouver l’état antérieur, la décision applicative, la transition enregistrée et le résultat authentifié. Pour soutenir une revendication d’interopérabilité, on rejoue avec l’accès externe coupé et avec une autre implémentation conforme.

Limite de preuve

Cet article n’attribue aucun incident à un produit, un parseur ou une organisation. Il ne dit pas que toute validation dépend du réseau ni que toute référence externe est exploitée. Il montre seulement pourquoi ces choix doivent être déclarés.

Il ne reprend pas non plus l’analyse existante de BTW sur YANG/XML, centrée sur l’arbre YANG effectif, les valeurs par défaut, les révisions de schéma, les montages, le datastore et l’effet réseau. Ici, l’objet est le chemin générique entre octets XML et décision applicative.

Les principes de spécification initiale minimale et de code en fonctionnement de Heng Lu sont des angles éditoriaux déclarés. Ils privilégient un contrat commun limité et des preuves issues de l’exécution ; ils ne décrivent pas un déploiement.

Le verdict tient en une phrase : si une ressource extérieure peut changer ce que le logiciel a reçu, elle fait partie du message opérationnel et de son histoire.

Sources