Résumé

  • La page « RPKI Trust Anchors - TAL » affiche deux URL sous /rpki/, mais son enregistrement de contenu associe ces libellés à deux chemins hérités sous /innovaportal/file/4983/1/.
  • Le 30 août, les deux URL affichées ont répondu 200 avec 7 014 octets de text/html parfaitement identiques. Les cibles des liens ont fourni deux TAL différents de 502 et 518 octets.
  • Les deux TAL désignent des certificats distincts, tous deux accessibles lors du contrôle. Rien ne permet donc de conclure à une panne de dépôt, à une mauvaise clé, à un rejet par un validateur ou à un effet sur le routage.
  • LACNIC devrait tester ensemble le texte visible, la cible résolue, le type de contenu, la grammaire TAL, le certificat nommé et l’historique de correction.

Un lien peut réussir et manquer sa promesse

La page publique de LACNIC présente d’abord le TAL ordinaire de l’organisation, puis celui qui accompagne la politique AS0. Elle explique qu’un TAL contient les emplacements du dépôt et la clé publique, avant d’annoncer deux téléchargements.

Ce que le lecteur voit est simple : /rpki/lacnic.tal et /rpki/lacnic-as0.tal sur l’hôte public de LACNIC. Pourtant, le contenu 4984 du CMS attache au premier texte le chemin /innovaportal/file/4983/1/lacnic.tal, et au second le même chemin se terminant par lacnic-as0.tal. Le fichier d’environnement du site indique que la base Innovaportal est innova.lacnic.net/innovaportal.

Le clic et la copie, gestes habituellement équivalents, cessent donc de l’être. Le clic suit l’attribut du lien vers le stockage historique. La copie utilise le libellé sous le nouveau domaine. Un contrôle manuel qui clique peut déclarer la page saine ; un script construit à partir du texte publié peut recevoir tout autre chose.

Ce n’est pas une subtilité réservée au HTML. Dans une documentation opérationnelle, une adresse est souvent reprise telle quelle dans un ticket, un playbook ou une recette d’installation. Le libellé devient alors une donnée, pas une décoration.

Deux fois 200, zéro TAL aux adresses écrites

Une collecte sans cache réalisée le 30 août 2026 à 04:48 UTC a demandé les deux adresses visibles. La première a répondu HTTP 200 avec le type text/html. La seconde a rendu la même combinaison.

Les deux réponses comptaient 7 014 octets et partageaient le SHA-256 7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416. Leur date Last-Modified était identique : le 28 août 2026 à 13:20:15 GMT. Leur contenu était la coque de l’application web LACNIC, et non deux documents TAL.

Cette date ne permet pas de dater le début du problème. Elle décrit les réponses observées, rien de plus. La collecte ne dit pas non plus si un opérateur a utilisé ces URL, si un cache les a traitées autrement ou si un validateur a vu le HTML.

Elle montre cependant la limite d’une sonde de disponibilité. Si la condition de succès est « statut 200 », les deux adresses sont vertes. Si la condition est « au moins une URI de certificat, une ligne vide, puis une clé publique conforme au format TAL », elles échouent avant toute décision de confiance.

Les fichiers utiles restent disponibles derrière le clic

La cible Innovaportal du TAL ordinaire a livré 502 octets, sous application/aux, avec le SHA-256 d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a. Elle commence par une adresse HTTPS et une adresse rsync vers le certificat ordinaire.

La cible du TAL AS0 a livré 518 octets et le SHA-256 671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff. Son dépôt, son certificat et sa matière de clé sont différents.

Le certificat ordinaire de 1 166 octets et le certificat AS0 de 1 160 octets ont eux aussi répondu 200. Ce constat ferme une porte importante : il ne serait pas sérieux de transformer un défaut d’alias public en verdict sur le dépôt de confiance.

La page ajoute que la plupart des outils de validation contiennent déjà les TAL nécessaires. Cette phrase n’annule pas l’importance de la distribution séparée, notamment pour AS0, mais elle interdit d’inventer un impact général à partir de deux URL mal alignées.

Le format donne le test à appliquer

Le RFC 8630 ne définit pas un TAL par son extension. Il demande une liste ordonnée d’URI de certificat, une ligne vide, puis l’encodage Base64 de la clé publique du point de confiance. Le validateur doit ensuite récupérer le certificat, vérifier qu’il s’agit d’un certificat CA RPKI auto-signé courant et comparer sa clé à celle du TAL.

On peut donc distinguer sans difficulté plusieurs preuves : résolution de l’adresse, arrivée d’une réponse, analyse comme TAL, récupération du certificat et concordance de clé. Le code HTTP n’est que la deuxième marche.

LACNIC doit en ajouter une en amont : le texte présenté au public et l’attribut réellement activé désignent-ils la même édition ? Il est parfaitement légitime de conserver une infrastructure historique, d’utiliser un service de téléchargement ou de rediriger une adresse stable. Ce qui doit disparaître, c’est l’ambiguïté sur l’adresse canonique.

Réparer sans inventer une crise

L’explication bénigne est la mieux étayée. Une nouvelle application web a repris les routes /rpki/ et renvoie sa page d’entrée ; l’ancien mécanisme de fichiers reste branché sur les liens du CMS. Les deux TAL réels et leurs certificats sont toujours accessibles. Aucun élément ne signale une attaque, une corruption ou une interruption de validation.

Deux corrections sont possibles. LACNIC peut modifier les textes pour qu’ils reproduisent exactement les cibles résolues. Ou bien elle peut faire des deux adresses affichées des alias effectifs, servant ou redirigeant vers le bon TAL. Dans les deux cas, cliquer et copier doivent conduire au même objet déclaré.

Une simple retouche silencieuse réglerait l’avenir mais effacerait le contexte des captures déjà faites. Une courte note de correction, ou mieux un reçu append-only, pourrait conserver l’ancienne paire, la nouvelle paire, l’heure de contrôle et la raison générale du changement. Cela suffit à éviter qu’une trace HTML ancienne soit plus tard prise pour une erreur de mesure.

Un reçu centré sur l’objet distribué

Pour chaque lien, le reçu devrait unir la version de page, le texte visible, le href brut, la cible absolue, le rôle ordinary ou AS0, le type attendu et la méthode de correction. Une sonde demanderait les deux adresses, et non seulement le href.

Elle enregistrerait le statut, le type de contenu, la taille et un condensat fort. Elle vérifierait ensuite la grammaire TAL, extrairait les URI et la clé, récupérerait le certificat préféré, puis noterait la validité de forme et la concordance de clé. Une anomalie de page resterait une anomalie de distribution tant qu’aucune preuve n’établit un problème cryptographique ou réseau.

Ce contrôle n’impose aucune nouvelle politique RPKI. Il rend seulement falsifiable une promesse déjà faite : le fichier nommé par la page est celui que reçoit le lecteur, qu’il clique ou qu’il copie.

Sources