Résumé

  • L'édition LACNIC figée au 28 août 2026 annonce 49 894 lignes d'enregistrement selon la définition du format RIR, alors que le fichier en contient 48 214. L'écart de 1 680 provient uniquement du résumé des ASN.
  • Les objets latest et daté étaient identiques octet pour octet, et leurs deux fichiers MD5 correspondaient. Cette cohérence de transport ne corrige pas le décompte et ne certifie pas la vérité de chaque enregistrement.
  • L'alias permanent ne disposait pas de latest.asc. La signature de l'objet daté était mathématiquement correcte, mais produite en 2026 avec SHA-1 et une clé DSA de 1 024 bits créée en 2002, combinaison que la norme OpenPGP actuelle interdit d'accepter.

Ce que voit d'abord un automate

Un programme qui récupère les statistiques déléguées n'a pas besoin d'interpréter l'histoire institutionnelle de LACNIC. Il commence par une ligne de version : 2|lacnic|20260828|49894|19870101|20260828|-0300. Le format publié donne à chaque champ un sens précis. 49894 doit être le nombre de lignes d'enregistrement, après retrait de la ligne de version, des lignes de synthèse, des commentaires et des blancs.

Les trois synthèses semblent confirmer ce total. Elles annoncent 20 375 lignes IPv4, 13 519 lignes IPv6 et 16 000 lignes ASN. Leur somme est bien 49 894. On pourrait donc croire que la validation interne est achevée avant même de parcourir le corps du fichier.

Le parcours produit un autre résultat. Le fichier compte 48 218 lignes physiques : une ligne de version, trois synthèses et 48 214 lignes de données. Le nombre IPv4 est exactement 20 375. Le nombre IPv6 est exactement 13 519. Pour les ASN, il n'y a que 14 320 lignes. Les 1 680 lignes d'écart ne sont ni dispersées ni dues à un arrondi ; elles correspondent à la différence entre la synthèse ASN et le corps ASN.

La prudence lexicale est ici une obligation technique. Le format explique que ses compteurs portent sur des lignes, et non sur la quantité totale de ressources représentées. Le résultat ne permet donc pas d'écrire que 1 680 ASN manquent, encore moins que 1 680 titulaires ont perdu un droit. Aucun enregistrement individuel n'a été déclaré faux par cette analyse. Ce qui échoue est la relation vérifiable entre l'en-tête et le fichier.

Cette relation devrait être banale. Le README de LACNIC présente le répertoire comme un ensemble de rapports quotidiens sur les allocations et les attributions IPv4, IPv6 et ASN. Le format commun prévoit l'alias delegated-<registry>-latest afin qu'une tâche planifiée puisse obtenir l'édition courante par une adresse persistante. Dans un produit conçu pour cette automatisation, le nombre d'enregistrements est une condition de contrôle, pas un commentaire éditorial.

La défense la plus sérieuse de LACNIC

Il serait trompeur de transformer cet écart en récit de corruption. Les contrôles effectivement publiés ont donné plusieurs résultats favorables.

Lors de la capture, delegated-lacnic-latest et delegated-lacnic-20260828 contenaient exactement les mêmes 2 311 991 octets. Leur empreinte SHA-256 commune était 95d59beaa4deb0ed5f40ae33a37210e11b4bce5b518613cfd4097fe442e7abf4. Les réponses HTTP partageaient aussi le même ETag et la même date de dernière modification. L'alias ne pointait donc pas vers une autre version que l'objet daté observé.

Les deux fichiers MD5 annonçaient 30f2fac07e846d1706c1fa8c7bb0ebd6. Le calcul indépendant a retrouvé cette valeur pour les deux objets. Le contrôle ancien a rempli sa fonction immédiate : rien n'indique une troncature ou une altération accidentelle entre la publication et la capture.

Enfin, la signature détachée de l'édition datée correspond réellement aux octets. L'audit a lu les paquets OpenPGP, reconstruit le condensat signé et vérifié l'équation DSA à partir de la clé publique distribuée par LACNIC. Le résultat mathématique est positif. Accuser la signature d'être fausse serait donc contraire aux preuves.

Ces constats favorables rendent la critique plus précise. LACNIC fournit des matériaux d'audit publics, sans contrôle d'accès. L'ancien format exige un MD5, qui est présent et correct. Il rend la signature PGP facultative ; l'absence d'une signature sur l'alias permanent n'est donc pas, à elle seule, une violation de cette ancienne clause. Le problème tient à la façon dont ces éléments se combinent pour un consommateur contemporain.

Quatre questions sous un même mot

Le mot « intégrité » dissimule plusieurs tests.

Le premier concerne le transport. Ai-je reçu les octets associés à la somme publiée ? Ici, le MD5 répond oui, dans les limites de cet algorithme. La RFC 6151 rappelle toutefois que MD5 n'est plus acceptable lorsqu'une résistance aux collisions est nécessaire. Il reste utile contre certaines erreurs ordinaires, pas comme preuve moderne d'identité de l'éditeur.

Le deuxième test concerne l'authenticité. Ces octets ont-ils été autorisés par le détenteur d'une clé que mon logiciel peut accepter ? La signature datée apporte une relation mathématique, mais l'alias automatique ne possède pas de fichier .asc correspondant à l'adresse attendue.

Le troisième test concerne la structure. Le fichier respecte-t-il les invariants qu'il déclare ? Sur le nombre de lignes, la réponse est non. Signer une incohérence ne la rend pas cohérente ; cela permet seulement à chacun de recevoir la même incohérence.

Le quatrième test serait la justesse sémantique de chaque ligne. Il est hors de portée ici. Le fichier se décrit comme un instantané sans détail transactionnel ni historique. Il ne prouve pas le routage BGP en direct, l'usage géographique, la propriété économique ou la succession complète des événements. Une preuve de publication doit éviter de prétendre résoudre ces questions qu'elle ne contrôle pas.

L'alias frais et la signature ancienne

L'architecture actuelle oblige le consommateur attentif à construire lui-même une chaîne. Il récupère latest, lit le numéro de série 20260828, fabrique le nom daté, vérifie que les deux contenus sont égaux, télécharge la signature datée, puis récupère la clé. Cette procédure peut fonctionner. Mais aucun objet signé par l'éditeur ne lie directement l'alias observé, l'édition datée et l'instant de publication.

Le maillon cryptographique daté ajoute une difficulté plus profonde. La clé principale porte l'empreinte BED3BE6115A8AF036D271F9D3B8DD165F3FB5533, utilise DSA avec un paramètre de 1 024 bits et a été créée le 12 décembre 2002. L'identité publiée est Auto Zone Generator. Aucune expiration de la clé principale n'apparaît dans l'autocertification examinée.

La signature, elle, a été créée le 29 août 2026. Elle utilise DSA et SHA-1. Son identifiant d'émetteur correspond à la clé publiée, et la vérification mathématique réussit.

La RFC 9580 impose pourtant une limite d'acceptation moderne. Une implémentation ne doit pas produire de nouvelle signature SHA-1, ni valider une signature récente qui dépend de SHA-1. Elle ne doit pas non plus signer ou vérifier avec une clé DSA. Le calcul forensique effectué pour établir ce qui a été publié ne transforme pas cette signature en objet acceptable pour une implémentation conforme.

Le calendrier de transition de NIST offre un contexte complémentaire : l'organisme veut sortir SHA-1 de toutes les applications de protection cryptographique au plus tard fin 2030 et recommande d'anticiper. Ce calendrier ne doit pas être déformé en interdiction autonome immédiate de NIST. Pour OpenPGP, la limite pertinente est déjà formulée dans la RFC 9580.

Un reçu de publication plutôt qu'une nouvelle autorité

La solution minimale consiste à déplacer la jointure vers l'éditeur. Chaque édition quotidienne devrait être accompagnée d'un petit reçu signé avec une clé et un algorithme modernes.

Ce reçu nommerait la date et le numéro de série, le fichier daté et l'alias latest, la taille en octets et le SHA-256, les nombres déclarés et réellement comptés par type, l'heure de coupure et le fuseau, l'empreinte et la période de validité de la clé, puis l'identité d'une correction ou d'un remplacement éventuel. Le reçu associé à latest désignerait explicitement l'édition datée.

Une telle pièce ne conférerait aucun pouvoir sur les décisions de routage des opérateurs. Elle ne prétendrait pas transformer un instantané en registre de propriété ou en journal d'événements. LACNIC attesterait seulement ce que LACNIC maîtrise : quels octets ont été publiés, sous quels noms, avec quels décomptes, par quelle clé et dans quelle chaîne de corrections.

La compatibilité ne demande pas d'abandonner immédiatement les anciens noms. Les fichiers et MD5 existants peuvent rester accessibles. Le reçu SHA-256 s'ajoute à eux. Une rotation de clé peut être reliée à la précédente par une déclaration de continuité. Les miroirs peuvent conserver les reçus, peu volumineux, même s'ils ne gardent pas toutes les éditions quotidiennes.

Le gain principal est institutionnel. Aujourd'hui, chaque consommateur sérieux doit décider s'il ignore le champ records, s'il accepte SHA-1, comment il relie latest au fichier daté et ce qu'il fait lors d'une correction silencieuse. Un reçu commun rend ces choix explicites et réduit la tentation de normaliser des exceptions privées.

Ce que les preuves ne disent pas

Elles ne démontrent ni attaque, ni compromission, ni faux enregistrement, ni perte d'allocation, ni anomalie de routage. Elles ne révèlent pas la cause interne des 1 680 lignes de différence. Elles ne montrent pas non plus qu'un utilisateur a subi un dommage. Elles établissent une incohérence publique reproductible et une chaîne d'authentification divisée entre deux noms de fichier.

C'est assez pour demander une amélioration, pas pour inventer une catastrophe. Une couche de coordination légère conserve sa légitimité lorsqu'elle formule peu de promesses, mais qu'elle peut toutes prouver.

Sources