Résumé

  • /.well-known/knowledge-linkset peut publier une carte typée d’artefacts et leurs empreintes, mais la concordance entre une carte et un fichier ne démontre pas que l’organisation en approuve le contenu.
  • Une mise en œuvre sûre doit conserver des décisions distinctes pour l’origine réseau, l’intégrité des octets, l’identité éditoriale, la confiance et l’autorisation opérationnelle.

Le contrôle avait commencé par une bonne nouvelle. Après une alerte sur un domaine institutionnel, l’équipe avait téléchargé le manifeste knowledge-linkset, récupéré un guide d’exploitation et recalculé son empreinte. Même algorithme, même valeur. Aucun octet ne manquait. Pourtant, le guide avait été remplacé, tout comme la valeur publiée dans le manifeste. L’attaquant ne s’était pas opposé au contrôle d’intégrité : il lui avait fourni deux pièces cohérentes.

Cette scène résume la limite essentielle du projet individuel déposé par Paul Besleaga le 30 septembre 2026. La révision 00 propose un emplacement prévisible, /.well-known/knowledge-linkset, où une origine pourrait décrire des ressources de connaissance au moyen de liens typés. L’idée répond à un problème réel : les documents lisibles par des machines sont dispersés entre catalogues, flux, graphes, fichiers de capacités, journaux et conventions locales. Une carte commune réduirait le coût de découverte.

Mais l’empreinte n’est pas un certificat de légitimité. Elle affirme qu’une représentation correspond à une valeur. Si l’autorité qui publie cette valeur est compromise, la vérification prouve la fidélité à l’état compromis. La bonne architecture ne rejette donc pas le hachage ; elle lui donne une mission limitée et refuse de lui prêter les missions des autres contrôles.

Ce que l’origine permet d’établir

RFC 8615 organise les URI bien connues sous une origine. Avec HTTPS, DNS et les certificats, un client peut déterminer quelle origine lui a répondu, dans les limites ordinaires de ces systèmes. Les RFC 8288 et 9264 fournissent ensuite un modèle pour relier des ressources. Le projet ajoute un profil spécialisé : des relations pour une ontologie, un graphe, des compétences, une surface, un état présent, un registre ou des pairs peuvent être annoncées dans un document JSON.

La révision demeure une proposition. Elle est une soumission individuelle active, sans groupe de travail ni directeur de domaine responsable, avec un statut Informational visé. Le nom bien connu demandé est provisoire et l’enregistrement du profil suit une démarche distincte. Cette absence de statut IETF formel ne condamne pas l’expérience. Elle interdit simplement d’utiliser le nom de l’IETF comme raccourci pour présenter le contenu découvert comme approuvé.

Le serveur contrôle la publication sous son origine. Ce contrôle est une provenance utile : on sait où l’assertion a été obtenue. Il n’indique pas nécessairement quelle personne l’a rédigée, quelle équipe l’a validée ni quelle filiale en assume la responsabilité. Une plateforme mutualisée peut servir des contenus de propriétaires multiples. Une migration peut déplacer la garde. Un compte d’administration compromis peut publier une carte et sa cible. La provenance d’origine est donc une donnée du raisonnement, pas sa conclusion.

Les Content-Digest décrits par les RFC 9530 et 9651 renforcent la comparaison des représentations. Un profil peut aussi imposer une canonicalisation, par exemple l’approche JSON de RFC 8785. Encore faut-il dire précisément ce qui est haché : octets transférés, contenu décompressé, objet canonicalisé ou autre représentation. Sans cette précision, deux implémentations honnêtes peuvent produire des valeurs différentes après négociation de contenu ou transformation intermédiaire.

Il faut également distinguer trois résultats. Une empreinte correspondante signifie « octets conformes à la valeur attendue ». Une empreinte divergente impose de refuser cette représentation et d’enquêter. Une empreinte absente signifie que ce mécanisme ne vérifie pas les octets ; elle ne suffit pas à déclarer la ressource fausse. Cette gradation évite de transformer un outil d’intégrité en oracle général.

Le texte découvert n’entre pas dans le plan de commande

Une relation nommée skills ou contribute peut aider un logiciel à choisir un document. Elle n’accorde aucun privilège aux phrases du document. Un agent peut classer, résumer et comparer un artefact sans considérer ses impératifs comme des instructions. Les commandes, demandes de secrets et tentatives de modifier la politique restent des données étrangères.

La séparation doit être technique. Le collecteur conserve l’URL initiale, la chaîne de redirections, l’adresse effectivement jointe, le type de média, la relation sélectionnée, le résultat du hachage, l’heure et la version du manifeste. Le modèle reçoit le contenu avec une étiquette de provenance. Le moteur d’autorisation reçoit une demande structurée pour une capacité précise. Si tout est fusionné dans une conversation où la politique locale et la prose distante se ressemblent, l’organisation a déjà perdu la frontière la plus importante.

Une signature HTTP conforme à RFC 9421 peut améliorer l’attribution : un détenteur de clé a signé des composants précis. La question de confiance subsiste. Cette clé est-elle reconnue pour ce type d’artefact ? Était-elle valable à cette date ? Peut-elle demander une lecture, une écriture ou un déploiement ? L’identité cryptographique ne produit pas automatiquement un mandat opérationnel.

Une carte qui déclenche des requêtes

Un lien n’est jamais seulement une ligne de données pour un robot. Il peut provoquer une connexion. Les pairs et redirections créent donc une surface SSRF. Un nom public peut résoudre d’abord vers une adresse publique puis, au moment de la connexion, vers une adresse privée. Une redirection peut mener vers l’adresse de métadonnées d’une infrastructure. Une notation inhabituelle peut cacher une boucle locale.

Le client doit normaliser les URL, limiter les schémas, rejeter les identifiants d’utilisateur ambigus, résoudre avec un composant contrôlé et bloquer les plages privées, locales, multicast et de métadonnées sauf autorisation explicite. Il doit vérifier à nouveau l’adresse réellement connectée, après chaque redirection et chaque nouvelle résolution. Un filtrage appliqué uniquement au texte de l’URL est insuffisant.

Le parcours des pairs exige aussi une enveloppe. Profondeur, nombre de nœuds, octets, durée, concurrence et requêtes par origine doivent être plafonnés. Les cycles se détectent sur des identifiants normalisés. Lorsque la limite est atteinte, le résultat est « partiel ». L’absence dans ce sous-graphe ne prouve pas l’inexistence dans le réseau complet.

La mémoire cache apporte une autre ambiguïté. RFC 9111 et les validateurs HTTP permettent une revalidation efficace. Un 304 Not Modified signifie que le serveur considère la représentation inchangée selon son validateur. Il ne renouvelle pas une preuve d’auteur. Pour une décision sensible, il faut retenir le manifeste qui a conduit à la ressource, son âge, son validateur et la politique appliquée. Sinon, une cible ancienne peut survivre à la disparition du lien qui l’autorisait supposément.

Le successeur n’est pas le même acteur

La proposition prévoit des tombstones et des liens vers des successeurs. C’est utile pour ne pas abandonner les clients devant un nœud disparu. Pourtant, la succession ne transfère ni identité ni garde. Le nouvel emplacement peut avoir d’autres opérateurs, licences, clés et pratiques. Le client doit enregistrer que l’ancien nœud affirme une succession, puis recommencer découverte et évaluation de confiance pour le nouveau.

Un registre d’évolution possède la même limite. Mémoriser une tête antérieure peut révéler un retour en arrière ou un remplacement. Si deux histoires concurrentes apparaissent, le registre ne choisit pas à lui seul la bonne. Il faut une règle de gouvernance extérieure : quorum, autorité nommée, procédure de récupération ou archive indépendante.

La publication de la carte révèle enfin une partie de l’organisation interne. Une ressource protégée peut rester inaccessible tandis que son nom, son type, son rythme de changement ou son empreinte deviennent publics. Une empreinte stable permet parfois de tester une hypothèse sur un document connu. Les opérateurs doivent pouvoir publier une vue publique réduite, réserver une vue complète aux clients authentifiés et omettre les métadonnées trop révélatrices. Une vue réduite doit être déclarée comme telle ; elle ne représente pas l’inventaire complet.

Le mérite de knowledge-linkset est de rendre visible l’architecture de connaissance d’une origine. Sa dangerosité apparaîtrait seulement si les utilisateurs confondaient cette visibilité avec une délégation. Le cas du manifeste et du guide remplacés ensemble fournit le test le plus honnête : le hachage fonctionne, mais il ne sauve pas l’organisation d’une mauvaise question. Il faut demander qui contrôle la racine de confiance, pas seulement si deux chaînes de caractères correspondent.

Sources