Résumé

  • La signature PKCS#10 prouve la possession de la clé de requête ; le BPKI authentifie un représentant autorisé et relie la demande au dossier membre d’AFRINIC.
  • Le certificat RPKI n’est délivré que si les ressources demandées sont un sous-ensemble de celles enregistrées pour le membre, sans attester publiquement son identité organisationnelle ou individuelle.
  • Une ROA valide autorise un ASN à être l’origine de préfixes précis ; elle ne prouve ni une annonce effective, ni la sûreté du chemin, ni l’acceptation par un opérateur.
  • Un reçu de provenance pourrait conserver versions, empreintes, décisions et horodatages sans révéler pièces d’identité, contacts privés ou secrets du portail.

Le nom opaque est une limite de fonction

Le Certification Practice Statement d’AFRINIC indique que le nom de sujet d’un certificat d’abonné peut être généré par l’émetteur et ne pas être parlant. Ces certificats servent à l’autorisation pour la sécurité du routage, non à l’identification. Sauf pour les registres, ils n’attestent pas l’identité de l’organisation détentrice ; ils n’attestent pas davantage l’identité d’une personne.

La page publique Resource Certification formule la même frontière : le certificat de ressources n’est pas un certificat d’identité. Il permet à des applications spécialisées de vérifier un droit d’usage sur des adresses IP ou des numéros de système autonome. Cette minimisation protège les membres : le validateur mondial n’a besoin ni d’un extrait de registre de commerce ni d’une pièce d’identité.

Sept questions derrière le mot « valide »

La première question porte sur la clé. Une requête PKCS#10 est signée par la clé privée correspondant à la clé publique demandée. Cela établit la possession de la clé à cet instant, pas un mandat ou un droit sur les ressources.

La deuxième porte sur le représentant. Seule une personne munie d’un certificat BPKI AFRINIC peut demander un certificat RPKI. La troisième est le lien vers le dossier : ce certificat BPKI rattache la requête à la base membres qui contient les enregistrements d’allocation.

La quatrième est une comparaison d’ensembles. AFRINIC ne délivre le certificat que si les ressources demandées sont incluses dans celles du membre. La cinquième concerne le certificat lui-même. RFC 6487 exige des extensions IP ou AS et un chemin où les ressources de l’émetteur englobent celles du certificat enfant.

La sixième question est posée par la ROA. Selon RFC 9582, elle autorise un ASN à annoncer des routes pour des préfixes et, le cas échéant, jusqu’à une longueur maximale. La septième est une observation : RFC 6811 dérive l’ASN d’origine d’une route BGP reçue et compare ce fait aux données ROA validées.

Chaque preuve s’arrête à sa frontière. Posséder la clé ne désigne pas le représentant. Le BPKI n’élargit pas les ressources. Le certificat de ressources ne choisit pas un ASN d’origine. La ROA n’annonce aucune route. Un résultat Valid ne certifie ni le chemin AS complet, ni la portée mondiale, ni la préférence appliquée par un réseau.

Le BPKI réalise la jointure qui n’apparaît pas publiquement

L’absence d’un nom d’entreprise ne permet pas de conclure qu’AFRINIC n’authentifie personne. Le CPS place l’identité du représentant et l’authentification des demandes dans le BPKI ; la base membres porte l’état des ressources ; le test de sous-ensemble limite l’émission. Le certificat public transmet ensuite seulement ce dont le tiers de confiance a besoin.

RFC 6480 décrit le même choix d’architecture : la RPKI fournit une autorisation plutôt qu’une authentification et le DN ne doit pas se présenter comme une identité descriptive. Il peut néanmoins servir à l’émetteur pour retrouver son dossier interne.

Ce dossier reste un enregistrement opérationnel d’AFRINIC. Il peut fonder une décision d’émission ; il ne devient pas pour autant un jugement de propriété, un mandat social ou la preuve de toute relation juridique extérieure.

Une ROA donne une permission ; BGP montre un événement

RFC 9582 précise que l’infrastructure utilisée pour valider une ROA apporte une autorisation, non une authentification ni une non-répudiation. Une ROA valable signifie que l’ASN indiqué est autorisé pour les préfixes indiqués. Elle ne dit pas qu’il les annonce actuellement.

Cette seconde information vient d’une vue BGP horodatée. Le validateur compare préfixe, longueur et origine observée aux VRP. Valid, Invalid ou NotFound sont des résultats de comparaison soumis à la politique locale. La page TAL d’AFRINIC fournit le point d’entrée vers l’ancre de confiance, mais un résultat reproductible requiert aussi l’état du dépôt, des manifestes, des CRL et de l’observation BGP.

Un reçu de provenance sans fichier d’identité public

AFRINIC pourrait exporter un reçu structuré. Il s’agit d’une recommandation éditoriale, non d’un engagement annoncé.

La partie registre contiendrait l’heure de la demande, l’empreinte de la clé, une référence BPKI non secrète ou un rôle, le résultat d’authentification, la version ou l’empreinte du dossier membre, l’instantané des ressources, la demande, le verdict de sous-ensemble, puis le numéro de série, le SKI, les extensions et la validité du certificat.

La partie validation conserverait point de publication, manifeste, CRL, TAL et heure. Pour une ROA : certificat EE, ASN, préfixes, maxLength, empreinte et résultat. Pour une validation d’origine : source BGP, heure, point d’observation, préfixe, origine constatée et comparaison.

Le membre pourrait garder le reçu complet dans son compte et ne publier que des références et empreintes. Un auditeur vérifierait les décisions sans recevoir de pièce d’identité, de contact privé ou de secret. Toute correction ou révocation pointerait vers la version remplacée. Le reçu indiquerait enfin ses limites : ni titre juridique, ni preuve d’annonce, ni garantie de chemin ou de portée mondiale.

Sources