Résumé

  • Une RSC valide établit qu’une partie disposant d’un contrôle suffisant sur l’AC émettrice a signé une liste associant un périmètre d’ASN ou d’adresses IP à des empreintes de fichiers. Elle n’établit pas l’identité réelle, le titre juridique, le mandat social ou la complétude du dossier.
  • L’acceptation doit conserver séparément le résultat CMS et certificat, le mode exact de correspondance de chaque fichier, les entrées non présentées et l’autorité externe qui identifie l’acteur et son pouvoir pour la décision considérée.

Prenons un dossier de cession d’actifs réseau. Le scénario est illustratif, pas le récit d’une transaction réelle. Le vendeur transmet un tableur d’adresses, une archive d’équipements et un fichier .sig. L’outil confirme les deux empreintes, la signature, la chaîne de certification, la CRL et l’inclusion des ressources annoncées dans le certificat EE.

Une troisième entrée figure pourtant dans la liste, sans fichier correspondant. RFC 9323 n’en fait pas automatiquement une erreur pour les deux objets effectivement fournis ; l’implémentation devrait avertir que la liste est plus longue que l’ensemble vérifié. Le comité transforme néanmoins le vert technique en preuve de propriété, de pouvoir de cession et de divulgation complète.

La cryptographie a répondu correctement. La question posée ensuite ne relevait plus d’elle.

Une assertion de ressources sur des octets

La RSC est un objet RPKI signé protégé par CMS. Son type id-ct-signedChecklist porte l’OID 1.2.840.113549.1.9.16.1.48. Le registre RPKI de l’IANA répertorie Signed Checklist et l’extension .sig; le type média est application/rpki-checklist.

L’objet contient un bloc de ressources, un algorithme de hachage et au moins une entrée. Le bloc doit inclure des AS, des blocs IP ou les deux. Chaque ressource déclarée doit être un sous-ensemble de l’extension RFC 3779 correspondante du certificat EE, sans forme inherit. Une ressource absente du certificat, un héritage interdit ou une structure mal formée invalide l’objet.

Chaque entrée porte une empreinte obligatoire et peut porter un nom de fichier portable. Les noms présents doivent être uniques entre entrées nommées ; les empreintes des entrées sans nom doivent être uniques entre elles. Cette discipline évite certaines ambiguïtés de correspondance. Elle ne renseigne ni la société, ni la fonction du porteur des identifiants, ni l’usage contractuel du fichier.

Quatre verdicts au lieu d’un voyant

RFC 6488 impose d’abord les contrôles communs : CMS SignedData encodé en DER, attributs autorisés, un seul certificat EE correspondant au SignerInfo, signature vérifiable et chemin valide vers une ancre RPKI. Le texte précise que ces conditions sont nécessaires mais insuffisantes ; le profil de l’objet ajoute ses propres règles.

RFC 9323 ajoute la syntaxe RSC, la contrainte de ressources, les règles de liste et l’absence obligatoire d’extension SIA dans le certificat EE. Le certificat doit être valide au moment du contrôle et non révoqué. Un objet auparavant valide cesse de l’être à l’expiration ou à la révocation de ce certificat.

Vient ensuite la vérification des fichiers. En mode sensible au nom, l’empreinte calculée doit correspondre et une seule entrée correspondante doit porter exactement le nom fourni. Sans nom, une seule entrée correspondante doit avoir son nom omis. Le choix ou le forçage du mode fait partie de la preuve opérationnelle.

Le quatrième verdict appartient à l’organisation : l’acteur réel a-t-il qualité pour agir, les pièces couvrent-elles les exigences de la décision, et le contenu est-il suffisamment vérifié ? Aucun succès des trois premières couches ne produit ce verdict.

Une empreinte ne lit pas le document

Le hachage porte sur les octets. Une déclaration fausse mais inchangée correspond parfaitement à son empreinte. Un inventaire signé n’établit pas que les équipements appartiennent au vendeur ; il établit seulement que les octets présentés sont ceux inscrits dans la liste signée.

Inversement, une transformation de fin de ligne ou d’encodage peut casser la correspondance d’un texte dont le sens paraît identique. RFC 9323 recommande une compression sans perte pour les objets textuels afin de limiter les changements de canonicalisation. Ce conseil protège l’identité binaire, pas la vérité sémantique.

Le nom du fichier ne résout pas davantage le problème. Il aide à exiger qu’une empreinte soit associée à un nom déterminé ; il ne certifie pas que inventaire contient tout l’inventaire.

La liste cryptographique n’est pas la liste des obligations

RFC 9323 autorise une vérification n’utilisant pas toutes les entrées. Cette souplesse est utile : chaque destinataire peut contrôler seulement les objets nécessaires à sa tâche. L’avertissement sur les entrées sans fichier laisse au destinataire le soin de décider si elles importent.

L’exhaustivité doit donc être définie hors de la RSC. Pour une cession, une matrice externe peut exiger titres d’enregistrement, affectations clients, sûretés, litiges, propriété des équipements, incidents et pouvoirs de signature. La RSC atteste les fichiers livrés qui correspondent à sa liste ; la matrice de diligence définit ce qui devait être livré.

Un rapport sérieux distingue les entrées appariées, les fichiers fournis mais non appariés, les entrées de RSC non présentées et les pièces requises par le processus mais absentes même de la RSC. Additionner ces états dans un pourcentage vert masque l’endroit exact où subsiste le risque.

L’infrastructure n’est pas une identité

RFC 9323 qualifie les données de la RSC d’auto-déclarées. Le relying party ne doit rien présumer au-delà d’un contrôle suffisant de l’AC émettrice pour créer l’objet. L’AC parente n’a pas vérifié le contenu de la liste.

RFC 9255 rappelle que le « I » de RPKI signifie Infrastructure, non Identity. La RPKI autorise des assertions relatives aux ressources Internet ; elle n’authentifie pas le détenteur réel ni une transaction commerciale.

Dans un service RPKI hébergé, le détenteur peut ne jamais manipuler la clé privée. Un compte demande au service CA de produire l’objet. Le titulaire des identifiants peut être un dirigeant, un administrateur réseau à compétence limitée, un prestataire ou un intrus. Même l’administrateur légitime n’a pas nécessairement pouvoir de céder un actif.

Les noms de sujet et d’émetteur du certificat ne comblent pas le vide : RFC 6487 ne les destine pas à décrire une identité. Il faut une autorité exogène — registre d’entreprise, décision du conseil, mandat contractuel, ordonnance, authentification connue — puis vérifier que le mandat couvre précisément l’acte et la date.

Hors dépôt, révocable et sans horodatage fiable

Les RSC ne sont pas distribuées dans le système de dépôts RPKI. Un tiers qui n’en reçoit pas de copie peut ignorer leur existence. Un trou de numérotation des certificats ou un numéro inconnu dans une CRL ne prouve donc ni l’existence ni l’absence d’une RSC.

Le canal de remise devient une pièce distincte. Un portail authentifié, un échange connu et un téléchargement anonyme peuvent livrer les mêmes octets tout en apportant des preuves différentes sur le présentateur et l’objectif. Le canal ne dispense pas de valider la RSC ; la RSC ne dispense pas d’établir le canal.

Le modèle normal associe un certificat EE à un objet, de sorte que la révocation du certificat révoque effectivement l’objet. Une AC peut techniquement réutiliser la même paire de clés pour plusieurs RSC, mais celles-ci ne peuvent plus être révoquées séparément. Le gain opérationnel crée une dépendance de gouvernance.

RFC 9589 rend obligatoire l’attribut CMS signing-time et interdit binary-signing-time, sans exiger que la valeur soit correcte. Elle n’est pas une preuve fiable de la date réelle de signature. Heure de validation, validité du certificat, CRL et chronologie contractuelle restent des éléments distincts.

Conserver aussi la portée négative

Le dossier d’acceptation doit contenir les octets et l’empreinte de la RSC, son canal, l’OID, le certificat, la chaîne, la CRL, le moment du contrôle, les deux ensembles de ressources, le mode de correspondance, chaque fichier, chaque entrée non utilisée, les avertissements, la source d’identité, le mandat et la décision finale.

Il doit surtout écrire ce qui n’a pas été prouvé : propriété, vérité, exhaustivité, pouvoir social, date de transaction ou autorisation d’origine BGP. Une preuve étroite est robuste tant que son destinataire respecte son périmètre. Elle devient dangereuse quand son apparente précision sert à éviter les contrôles externes.

Sources