Résumé

  • La page du W3C attribue w3.org/2026/08/xmldsig-more# à XML Security, mais son lien vise la dernière version du brouillon et non une révision identifiée.
  • La révision -08 employait encore w3.org/tbd#; la révision -09, publiée deux jours après la date de la page W3C, introduit l’espace de noms définitif tout en ajoutant d’autres éléments.
  • Les propres textes du W3C demandent qu’une politique précise comment des noms peuvent être ajoutés ou retirés et par qui. Le silence actuel ne permet de conclure ni à la mutabilité ni à l’immutabilité.
  • Une constitution d’évolution doit associer l’allocation à une version et à son empreinte, borner les changements avant gel, nommer l’autorité de gel et distinguer les actes du W3C, de l’IETF et de l’IANA.
  • Rien ne prouve une allocation invalide, une approbation d’algorithme, une adoption IETF ou un retard de l’IANA. Le problème est la lisibilité de la chaîne de garde, non la légitimité du travail.

Deux dates, une question de garde

La page d’espace de noms du W3C affirme que l’URI a été alloué à XML Security, renvoie au brouillon RFC 9231bis dans le Datatracker et indique une dernière révision par Simone Onofri le 19 août 2026. Elle ne donne ni numéro de version, ni empreinte, ni lien vers la décision d’allocation, ni règle de modification des noms locaux.

Il serait facile de présenter cette concision comme une faute. Ce serait aller trop vite. Allouer tôt un URI persistant permet de remplacer les marqueurs provisoires, d’éviter des collisions et de mener des essais entre spécifications. Le W3C fournit ainsi une pièce d’infrastructure utile sans prétendre que tout ce qui sera placé sous le préfixe est approuvé.

La difficulté naît de la forme du lien. Il conduit toujours au dernier brouillon. C’est excellent pour trouver l’état courant, insuffisant pour reconstituer l’état autorisé. La découverte répond à « où en est le texte ? » ; la garde répond à « quel texte l’autorisation couvrait-elle et qui pouvait ensuite le modifier ? »

Le lieu de coordination s’est transformé

L’issue 484 du dépôt Strategy du W3C avait été ouverte le 17 novembre 2024 pour envisager un atelier consacré à la cryptographie post-quantique dans XML Signature et XML Encryption. Cette trace publique montre une coordination réelle. Elle n’est ni une Recommendation, ni une charte, ni une décision de transition.

Le 21 novembre 2024, l’auteur du brouillon individuel a proposé d’y ajouter des algorithmes. Le 14 juin 2025, une contribution a dressé la liste HSS/LMS, ML-DSA, SLH-DSA et ML-KEM, tout en suggérant que l’issue GitHub puisse remplacer l’atelier. Ce sont des actes de collaboration ouverts, pas des actes d’approbation institutionnelle.

Le 17 août 2026, l’issue signalait que -08 couvrait les quatre familles suivies et que -09 était en préparation avec d’autres éléments. La page d’espace de noms est datée du 19. L’auteur a annoncé -09 le 21 août. Enfin, le 26 août, l’objet de l’issue a été reformulé : il ne s’agissait plus d’organiser un atelier, mais de suivre les besoins de mise à jour d’XML Signature et d’XML Encryption.

Cette évolution n’est pas un échec. Elle montre au contraire que le travail savait s’adapter. Elle montre aussi pourquoi une permission attachée à un espace de noms ne devrait pas dépendre uniquement d’un pointeur vers « latest ». Le forum, les participants et le contenu peuvent changer alors que l’URI demeure.

Le brouillon porte deux états publics compatibles

Au 1er septembre, la fiche Datatracker présentait -09 comme un Internet-Draft individuel actif, à l’état I-D Exists, sans stream RFC défini ni Area Director responsable. Le dépôt d’un Internet-Draft n’est pas une adoption par l’IETF.

L’en-tête du document dit pour sa part « Independent », « Obsoletes: 9231 (if approved) », vise le Standards Track et fixe une expiration au 22 février 2027. Ces indications expriment l’intention de l’auteur et un effet conditionnel. La fiche Datatracker exprime la position institutionnelle attribuable. Il n’y a pas lieu d’accuser l’une des deux surfaces d’erreur.

La révision archivée -08, datée du 26 mai, emploie w3.org/tbd# pour les nouveaux identifiants. Son SHA-256 est cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f.

La révision -09, datée du 21 août, remplace ces marqueurs par w3.org/2026/08/xmldsig-more#, ajoute l’annexe de schéma correspondante et apporte encore d’autres modifications. Son empreinte est 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b.

L’historique officiel des révisions confirme les dates du 26 mai et du 21 août, sans faire apparaître d’adoption par un Working Group, d’affectation à un stream ou de prise en charge par un Area Director.

On peut donc prouver la substitution du préfixe et l’ordre des publications. On ne peut pas prouver les octets examinés par le W3C. On ne peut pas davantage prétendre qu’aucun dossier interne n’existe. La lacune est celle du raccord public.

L’URI, le document et le registre ne forment pas une seule autorité

Le point de référence approuvé reste le RFC 9231. Il régit la génération précédente et rappelle déjà qu’un URI xmldsig-more ne vaut pas statut officiel d’un algorithme auprès du W3C ou de l’IETF.

Le registre XML Security URIs de l’IANA continue logiquement à citer le RFC 9231. Sa politique est Specification Required et des experts désignés y sont nommés. Tant qu’un successeur n’est pas approuvé ou qu’une autre voie valable n’est pas empruntée, cet état n’est ni un retard ni un refus.

Le W3C garde un URI dans son espace web. Un processus documentaire de l’IETF peut faire mûrir puis éventuellement approuver une spécification. L’IANA applique une politique de registre. L’auteur du brouillon peut éditer son texte, mais ne devient pas pour autant gardien des règles d’espace de noms du W3C. L’allocation par le W3C ne vaut pas approbation d’un RFC. L’inscription future par l’IANA ne vaudrait pas consigne de déploiement.

La question manquante se situe entre ces fonctions : quel événement transforme la génération 2026, encore liée à un texte mouvant, en vocabulaire gelé ?

Le W3C a déjà écrit la règle générale

Le guide du W3C sur les espaces de noms reconnaît les formes datées et indique que @w3c/transitions les alloue et les autorise dans des pull requests du dépôt w3c/ns. Il explique aussi que la persistance pendant la discussion est un service utile et que l’allocation n’emporte aucun aval officiel.

Surtout, ce guide demande aux groupes de dire clairement comment les espaces de noms qu’ils contrôlent évolueront ou n’évolueront pas. Cette attente doit figurer dans le document de l’espace de noms ou être clairement reliée depuis celui-ci.

Le finding du TAG sur le devenir des noms va plus loin : une spécification devrait expliciter sa politique de changement ; si l’espace n’est pas immutable, elle devrait préciser comment des noms sont définis ou retirés et par qui. En l’absence d’une déclaration explicite, on ne peut pas déduire l’immutabilité.

Le silence de la page 2026 n’autorise donc aucune conclusion commode. Il ne prouve ni que -09 est déjà gelé, ni que tout éditeur futur peut librement changer les noms.

La politique de persistance des URI confirme que les ressources datées entrent dans la promesse de persistance, tout en pouvant être modifiées avec conservation d’un historique. Persistance de l’adresse et immobilité du vocabulaire sont deux propriétés différentes.

Il ne s’agit pas de déclarer l’allocation contraire aux règles. Une autorisation peut exister ailleurs. Il s’agit de publier la règle là où les utilisateurs de l’URI ont reçu instruction de la chercher.

Les générations antérieures ont toutes un moment de gel

Le texte de -09 qualifie le préfixe de 2000 de « Frozen by W3C », puis associe les générations 2001, 2007 et 2021 respectivement aux RFC 4051, 6931 et 9231. Le gel apparaît comme un acte historique identifiable.

Pour la génération 2026, la page ne dit pas ce qui est permis avant cet acte. Peut-on ajouter un nom ? Retirer celui qu’un logiciel teste déjà ? Réserver une ancienne graphie ? Une approbation RFC suffit-elle à geler le tout, ou une décision W3C distincte est-elle nécessaire ? Après le gel, faut-il un nouveau préfixe daté ?

Le bon article de gouvernance ne choisit pas les réponses à la place des autorités. Il demande que les autorités remplissent les cases avant que les dépendances installées imposent leur propre réponse.

La syntaxe d’identifiant ne décide pas de la cryptographie

Les Recommendations XML Signature 1.1 et XML Encryption 1.1 montrent pourquoi des identifiants stables sont nécessaires à l’interopérabilité des structures XML. Elles ne valident pas automatiquement tout algorithme auquel un URI pourrait être attribué.

Le projet conserve une politique Specification Required. Le RFC 8126 associe cette politique à une spécification publique et permanente ainsi qu’à l’examen d’un expert. Ce contrôle d’admission n’est pas une certification universelle de sécurité.

Le présent dossier ne compare donc aucun algorithme et ne conseille aucune migration. Il ne conclut ni à la sûreté, ni à l’implémentation, ni au déploiement d’une des familles nommées. La question de changement serait identique pour n’importe quel vocabulaire logiciel durable.

Une constitution en quinze champs

Le document public nécessaire peut rester court. Il devrait identifier l’URI et sa classe datée ; la décision d’allocation, son auteur institutionnel, sa date et son lien public ; la révision et l’empreinte examinées ; puis la révision actuellement visée.

Il devrait séparer l’ajout, la correction, le renommage, le retrait et la dépréciation d’un nom. Pour chaque classe, il faut indiquer qui propose, qui décide et quel traitement est réservé aux références ou implémentations existantes.

Il devrait nommer l’événement de gel, son décideur et son horodatage. La règle post-gel dirait si une extension emprunte le même préfixe, une expertise IANA, un erratum, un RFC successeur ou une nouvelle génération datée.

Enfin, il devrait afficher séparément le gardien W3C de la page, la classe et l’état IETF du document, le stream, le groupe et l’Area Director lorsqu’ils existent, puis la politique IANA et la compétence des experts. La source de la syntaxe d’identifiant doit rester distincte de la source de la sémantique algorithmique. Corrections, succession, expiration et prochaine revue complètent la trace.

Six actes ne doivent jamais se réduire à un seul statut : allocation du namespace, publication du brouillon, adoption ou affectation IETF, approbation RFC, mise à jour IANA et déploiement par un protocole ou un opérateur.

Une telle constitution ne révèle ni débat confidentiel ni rapport d’implémentation sensible. Elle préserve seulement la version, le pouvoir et la transition.

Une critique de la lisibilité, pas des acteurs

Les éléments publics sont solides : l’issue est ouverte, les versions sont archivées, le W3C persiste l’adresse, l’IANA conserve le bon RFC et le brouillon nie lui-même toute approbation implicite. Aucun élément ne révèle mauvaise foi, capture, action de registre non autorisée ou collaboration rompue.

Précisément parce que les briques existent, leur raccord est peu coûteux. Un lien dynamique peut guider vers le présent. Seule une règle versionnée peut expliquer le passé et borner le prochain changement.