Résumé

  • RFC 8805 décrit des données géographiques grossières, autopubliées par préfixe, que le consommateur peut traiter comme un simple indice.
  • RFC 9632 peut relier un fichier signé à l’autorité sur l’espace d’adresses couvert, sans certifier la réalité physique du lieu.
  • Une correction solide relie la révision signée au téléchargement, à l’activation, à la résolution des chevauchements et au résultat observé.

Signature valide, carte toujours fausse

Un opérateur déplace un préfixe vers une autre ville, met à jour son geofeed et ajoute l’authentificateur RPKI facultatif. La validation réussit. Pourtant, plusieurs jours plus tard, un catalogue vidéo, un contrôle antifraude ou un choix de CDN affiche encore l’ancienne ville.

La signature n’a pas échoué : elle prouve autre chose. RFC 9632 vérifie que le signataire est autorisé pour les ressources couvertes et que les octets canoniques correspondent. HTTPS protège le point de récupération, mais le WebPKI ne prouve pas l’attribution de l’espace IP.

RFC 8805 définit un CSV simple associant préfixe, pays, région et ville. Le format reste volontairement grossier. Le consommateur peut le considérer comme un indice, préférer d’autres sources et doit distinguer autorité et exactitude. La cryptographie n’observe pas la position réelle des routeurs, des utilisateurs ou des services.

RFC 9632 ajoute la découverte via l’attribut geofeed: d’un objet RPSL inetnum:. Le consommateur choisit encore quand récupérer le fichier, comment traiter le préfixe le plus spécifique, quelles données fusionner et quand activer une version. Comme les lectures en temps réel fréquentes sont déconseillées, l’âge du cache fait partie de la preuve.

L’enquête utile suit un préfixe depuis le hash du fichier et la couverture du certificat jusqu’à l’objet de découverte, l’heure de récupération, le parseur, la règle de chevauchement, la version du jeu de données, le lieu activé et les observations externes. « Signature valide » ne clôt que l’authentification.

Sources