Résumé

  • La RFC 9323 de Job Snijders, Tom Harrison et Ben Maddison permet de vérifier qu’une clé autorisée pour un sous-ensemble donné d’adresses IP ou d’ASN a signé une liste d’empreintes de fichiers exactement déterminés.
  • Une RSC valide ne prouve ni l’identité réelle du signataire, ni son mandat dans une société, ni la véracité du document, ni la légalité de l’opération. Le destinataire doit encore vérifier ces éléments et reste libre d’accepter ou de refuser la demande.

Le document, le préfixe et la mauvaise question

Lorsqu’un client apporte ses propres adresses IP à une plateforme, la question semble tenir en une phrase : peut-il demander à ce fournisseur d’annoncer ce préfixe ? En réalité, plusieurs preuves se superposent. Il faut identifier le compte, établir le rôle de la personne, relier la demande aux ressources numériques, examiner les pièces et décider si l’opération est sûre.

Une lettre signée à la main peut nommer une entreprise sans établir de manière automatisable son autorité sur les adresses. Un certificat de ressources peut couvrir les bons numéros sans nommer juridiquement l’entreprise. Le piège consiste à demander à l’un de ces instruments de répondre à toutes les questions.

La RFC 9323, publiée en novembre 2022, choisit une voie plus disciplinée. Job Snijders, Tom Harrison et Ben Maddison y définissent la RPKI Signed Checklist, ou RSC. Cet objet CMS contient un algorithme de condensat, au moins une ressource Internet et une ou plusieurs entrées associant une empreinte à un fichier externe.

La liste ne transporte pas les fichiers. Elle permet au destinataire de recalculer leur empreinte et de vérifier qu’elle correspond aux octets visés par la signature. La formulation correcte n’est donc pas « ce document est vrai », mais « ces octets figurent dans une liste signée par une clé autorisée pour cet ensemble de ressources ».

Cette précision raconte aussi le travail de Snijders. Le Datatracker de l’IETF le relie à plusieurs travaux de sécurité du routage. OpenBSD le cite parmi les principaux développeurs de rpki-client et comme mainteneur de sa version portable. Le fil commun n’est pas la promesse d’une confiance totale, mais la construction de preuves que l’on peut délimiter et tester.

Ce que l’objet relie exactement

Le contenu d’une RSC énumère des blocs d’adresses IP ou des identifiants de systèmes autonomes, un algorithme de hachage et des éléments de liste. Chaque élément porte un condensat et peut porter un nom de fichier. Au moins une ressource numérique doit être présente.

L’ensemble indiqué dans la liste doit rester inclus dans celui du certificat d’entité finale embarqué. La clé ne peut donc pas étendre par simple déclaration son champ d’autorité. Une RSC qui mentionne un préfixe ou un ASN absent du certificat doit échouer à la validation.

L’empreinte verrouille une séquence d’octets. Une modification minime du fichier produit normalement un autre résultat. Cette propriété détecte une substitution ou une altération ; elle n’évalue pas une phrase, ne vérifie pas une facture et ne juge pas si le fichier convient à la demande commerciale.

Le nom de fichier est optionnel. Dans une validation sensible au nom, le nom et l’empreinte doivent tous deux correspondre. Dans une validation qui ignore le nom, l’entrée correspondante ne doit pas en contenir. Le protocole distingue ainsi deux besoins légitimes : attester un paquet nommé ou attester seulement son contenu exact.

Cette nuance interdit de confondre une étiquette rassurante avec une preuve. Un fichier appelé autorisation.pdf peut être faux ; un fichier renommé peut conserver exactement les mêmes octets. Le processus doit annoncer quelle forme de correspondance il exige.

Une clé jetable et un pouvoir limité

Chaque RSC emploie une nouvelle paire de clés et un certificat d’entité finale à usage unique. Après la création de l’objet, la clé privée doit être détruite. Le certificat ne contient pas l’extension SIA qui servirait à pointer vers un dépôt RPKI public.

Ce choix réduit la réutilisation et la corrélation. Le certificat n’est ni un badge permanent ni une identité de connexion. Il sert à vérifier un objet précis dans la hiérarchie des certificats de ressources. L’expiration ou la révocation peut ensuite rendre cette preuve invalide selon les règles générales des objets signés RPKI.

La RFC 6480 explique la limite fondatrice : un certificat de ressources lie une clé publique à des adresses IP ou à des ASN, mais n’atteste pas l’identité descriptive du sujet. La RSC hérite de cette frontière au lieu de la contourner.

La RFC 9255 va plus loin. Elle avertit qu’un identifiant RPKI ne doit pas authentifier des documents ou transactions du monde réel. La personne qui administre un compte de ressources peut n’avoir qu’un rôle technique étroit. Elle n’est pas nécessairement dirigeante, mandataire ou habilitée à engager l’entreprise.

Une signature techniquement valide peut donc provenir du bon domaine de ressources et de la mauvaise autorité commerciale. Ce n’est pas une contradiction. Ce sont deux assertions confiées à deux systèmes différents.

Valider sans surinterpréter

Le destinataire commence par vérifier l’enveloppe CMS, la chaîne de certificats, les ressources et les contraintes propres à la RSC. Il calcule ensuite l’empreinte de chaque fichier qu’il choisit d’examiner et recherche l’élément correspondant dans la liste.

Il peut vérifier moins de fichiers que la liste n’en contient. La RFC 9323 ne transforme pas les éléments inutilisés en erreur fatale, mais recommande un avertissement. Celui-ci peut révéler une pièce oubliée, une différence de procédure ou une tentative de présenter un dossier incomplet.

La RFC 6488 rappelle que les contrôles génériques d’un objet signé sont nécessaires mais insuffisants. Chaque type d’objet possède une sémantique propre. La RFC 6487 définit le profil des certificats de ressources et la RFC 9286 précise l’algorithme de validation. Une enveloppe correcte n’est jamais une lecture intelligente du document qu’elle référence.

Même l’heure de signature demande de la retenue. Un attribut CMS peut indiquer un instant, mais les règles génériques n’en font pas une horloge de transaction faisant autorité. Si le métier exige une date opposable, il lui faut un reçu ou un journal conçu pour cette fonction.

Le résultat devrait donc rester composé. Signature valide, ressources couvertes et octets identiques sont trois conclusions techniques. Identité confirmée, mandat établi, contrat accepté et déploiement sûr sont d’autres conclusions. Les fusionner dans un voyant vert détruit l’information que la cryptographie venait justement d’apporter.

Hors du dépôt mondial

La RFC 9323 interdit de distribuer les RSC dans le système mondial de dépôts RPKI. Le transport reste volontairement extérieur au format : HTTPS, courrier électronique, support amovible ou canal défini entre les parties.

Le registre RPKI de l’IANA attribue à la Signed Checklist l’identifiant 1.2.840.113549.1.9.16.1.48 et l’extension .sig. Ces références assurent l’interopérabilité des logiciels ; elles ne créent ni boîte aux lettres centrale ni obligation d’accepter l’objet.

Cette architecture protège une information parfois sensible. Les pièces d’un onboarding ou d’une interconnexion appartiennent à une relation déterminée. Publier mondialement les associations entre ressources et dossiers pourrait exposer des clients ou des projets sans améliorer la validation des origines de routes.

Le revers est clair : le canal doit assurer lui-même l’authentification, la confidentialité, la disponibilité et la conservation. La RSC détecte un écart entre les octets reçus et les empreintes. Elle ne prouve pas qui contrôlait la boîte mail, ne bloque pas un logiciel malveillant et ne garantit pas que toutes les pièces sont arrivées.

Le destinataire garde le dernier mot

Imaginons une plateforme recevant une RSC valide pour un préfixe et trois pièces de BYOIP. Elle sait que la chaîne de ressources couvre le sous-ensemble annoncé et que les fichiers correspondent aux empreintes. C’est une réduction substantielle de l’incertitude.

Elle ne sait pas encore si l’utilisateur du compte représente la société, si le contrat permet l’annonce, si une autre partie exploite déjà le préfixe, si la demande respecte les règles applicables ou si la mise en service créera un conflit de routage. Elle doit réunir ces preuves ailleurs.

Le bon enchaînement n’oppose pas automatisation et jugement. Les contrôles déterministes peuvent être entièrement automatisés, avec des motifs d’échec précis. Les contrôles d’identité, de mandat, de conformité et de réseau peuvent aussi suivre des politiques automatisées, à condition de rester des états séparés.

Ainsi, une RSC valide peut accompagner un refus commercial légitime. Des fichiers identiques peuvent être dépassés. Un administrateur de ressources authentique peut ne pas avoir le pouvoir de conclure l’opération. Et un fournisseur peut demander davantage de garanties sans contester la validité cryptographique.

Cette séparation place la décision auprès de celui qui supporte le risque. Le standard coordonne une preuve commune ; il ne nationalise pas les procédures des clouds, opérateurs, points d’échange ou entreprises.

Déploiement : constater plutôt que supposer

Une norme publiée n’est pas un service universel. Le plan trimestriel RPKI du RIPE NCC mentionne un support API des RSC prévu au troisième trimestre 2026 après des demandes de la communauté. Une interface utilisateur ultérieure dépendrait de la demande et de la capacité disponible.

Cette indication prouve un chemin d’implémentation, pas l’adoption générale. Il faut vérifier quels portails produisent l’objet, quels validateurs le comprennent, quels fournisseurs l’acceptent et comment chaque application expose les avertissements. Une chaîne est aussi robuste que son maillon le moins explicite.

Les tests devraient couvrir l’expiration, la révocation, les transferts de ressources, les pièces absentes, les changements de nom, la vérification partielle et les algorithmes non reconnus. Ils devraient surtout simuler le cas organisationnel central : le compte RPKI est bien contrôlé, mais son opérateur n’a pas de mandat commercial.

Le profil MENOG replace Snijders dans une communauté de routage et de peering où une preuve doit survivre au contact d’opérateurs différents. La RSC porte cette culture : un petit mécanisme commun, puis des décisions locales explicites.

La valeur d’une preuve qui sait s’arrêter

Un condensat ne connaît que des octets. Un certificat de ressources ne connaît qu’une relation entre une clé et des numéros sous un modèle de confiance. Leur combinaison peut répondre avec force à une question limitée. Elle devient trompeuse dès qu’une application ajoute silencieusement identité, intention ou légalité.

Le mérite de la RSC est donc double. Elle offre aux détenteurs de ressources une preuve portable et aux destinataires un contrôle reproductible. Elle empêche aussi, par son architecture et ses avertissements, de transformer cette preuve en permis général.

Job Snijders et ses coauteurs n’ont pas supprimé la confiance humaine ou institutionnelle. Ils ont isolé l’endroit où la machine peut réellement conclure. Dans une infrastructure distribuée, cette modestie augmente la confiance au lieu de la diminuer.

Sources