Résumé

  • La feuille de route NRO, modifiée en décembre 2025, classait les certificats TA à durée courte parmi les fonctions RPKI essentielles ; APNIC, ARIN et LACNIC les proposaient alors, avec une cible commune fixée à la fin de 2025.
  • Le 29 août 2026, le TAL publié par AFRINIC renvoyait toujours un certificat racine autosigné valable du 30 mars 2020 au 28 mars 2030.
  • La comparaison établit un dossier public incomplet, non une défaillance : les sources ne définissent pas la durée maximale de « short-lived » et ne prouvent ni rejet de validation, ni route invalide, ni incident de clé.
  • Il faut publier une preuve de mise en service reliant définition, émission, clé stable du TAL, disponibilité du dépôt, rafraîchissement observé, exceptions, retour arrière et corrections.

Une échéance sans état de sortie

La ligne tient dans un petit tableau. « Short-lived TA certificates », indique la feuille de route du programme RPKI de la NRO. Dans la colonne des fournisseurs présents figurent APNIC, ARIN et LACNIC. Dans la colonne suivante, le déploiement chez tous les RIR est promis pour la fin de 2025.

La page a été modifiée le 2 décembre 2025. À cette date, elle décrivait donc encore un objectif, pas un constat de clôture. C’est le rôle normal d’une feuille de route. Elle devient insuffisante lorsque l’échéance passe sans qu’un nouvel objet documentaire dise ce qui s’est produit : réalisation, report, exception, remplacement par un autre contrôle ou redéfinition de la fonction.

Le matériel public d’AFRINIC permet de poser la question sans spéculation. Le 29 août 2026, son Trust Anchor Locator était accessible. La première adresse du TAL désignait AfriNIC.cer dans le dépôt RPKI du registre. Le fichier DER récupéré comptait 1 216 octets. Son sujet et son émetteur étaient tous deux AfriNIC-Root-Certificate. Son numéro de série était E5CF72BA6C7E9E28. Sa validité commençait le 30 mars 2020 et se terminait le 28 mars 2030.

Le dépôt répondait et le certificat pouvait être inspecté. Ces observations ne signalent pas une panne. Elles établissent seulement que l’artefact visible huit mois après la cible commune affiche encore une durée proche de dix ans.

Plusieurs explications favorables restent possibles. La page NRO peut être en retard sur la production. AFRINIC peut avoir préparé ou testé un changement qui n’a pas encore donné lieu à une nouvelle émission. Une exception peut exister. Le certificat ancien peut être maintenu pendant une transition prudente. Le terme « durée courte » peut enfin reposer sur une définition précise qui n’est pas reliée aux pages examinées.

Le dossier ne permet pas de choisir. Une infrastructure digne de confiance ne devrait justement pas demander au lecteur de choisir à sa place.

L’adjectif ne fournit pas le seuil

Dix ans paraissent longs. Cela ne suffit pas à déclarer formellement que la cible a été manquée.

La feuille de route ne fixe ni durée maximale, ni cadence de renouvellement, ni période de chevauchement, ni autorité compétente pour accorder une exception. Elle ne dit pas si le critère est de deux ans, d’un an, de quatre-vingt-dix jours ou d’une autre durée. L’article ne peut inventer ce que le programme n’a pas rendu public.

Le certificat reste pourtant une preuve importante. Il ne s’agit pas d’un communiqué ou d’une intention. C’est un objet opérationnel obtenu à partir de l’adresse inscrite dans le TAL d’AFRINIC. Il permet de conserver une date d’observation, un numéro de série, une empreinte, une période de validité et une localisation.

Il faut donc distinguer trois états. L’engagement décrit le résultat recherché. L’artefact montre ce qui est servi à un instant délimité. L’acceptation explique pourquoi l’acteur responsable considère cet artefact conforme à l’engagement. La première ligne n’exécute pas la deuxième ; la présence de la deuxième ne remplace pas la troisième.

Un registre honnête peut employer des états simples : réalisé selon la définition publiée ; réalisé avec exception ; reporté avec nouvelle échéance ; remplacé par un contrôle équivalent ; non achevé. Une absence de mise à jour n’est pas un état technique supplémentaire.

La stabilité du TAL n’impose pas l’immobilité du certificat

Le RFC 7730 fournit la mécanique utile. Un TAL contient les emplacements où récupérer le certificat et le matériel de clé publique qui permet de le vérifier. L’objet récupéré doit être un certificat CA RPKI autosigné et courant. Sa clé publique doit correspondre à celle du TAL.

Le même texte demande que la clé de l’ancre reste stable lors d’une réémission motivée par une modification des ressources ou par un renouvellement avant expiration. Le certificat de remplacement demeure disponible à l’adresse stable. Autrement dit, continuité de confiance et durée du certificat sont deux variables différentes.

AFRINIC peut donc, en principe, conserver la clé connue des relying parties tout en réémettant plus souvent le certificat qui porte les ressources et les dates courantes. Une durée plus courte ne signifie pas que chaque opérateur doit accepter une nouvelle racine à chaque cycle. Le changement de clé constitue une opération distincte.

Cette architecture transforme néanmoins la mise en service en chaîne. Le registre doit émettre correctement. Le dépôt doit publier au bon emplacement. Le validateur doit récupérer l’objet, vérifier qu’il est actuel et autosigné, comparer sa clé à celle du TAL, puis appliquer ses propres contrôles d’acceptation. Le RFC recommande ces vérifications lors de la resynchronisation du dépôt et avant l’expiration de la copie locale.

Une émission ne prouve donc pas, seule, la réception. Une date de feuille de route prouve encore moins. Il faut relier politique de durée, émission, correspondance de clé, publication, observations de rafraîchissement et traitement des exceptions.

Cette chaîne ne constitue pas non plus une mesure de routage. Les sources figées ne montrent aucun préfixe devenu RPKI Invalid, aucun routeur ayant rejeté une annonce, aucun échec de dépôt et aucun validateur conservant un objet erroné. Ces conséquences exigeraient des observations propres.

Une durée courte déplace le risque

Le meilleur argument en faveur d’un certificat plus bref n’est pas « court égale sûr ». Une période réduite limite le temps pendant lequel un ancien certificat peut continuer à représenter l’état courant et oblige l’organisation à exercer régulièrement son processus de renouvellement.

Le bénéfice dépend de l’automatisation. Des réémissions fréquentes testent plus souvent la chaîne de création, de publication et de récupération. Elles peuvent révéler une fragilité avant qu’un renouvellement exceptionnel ne se transforme en crise. Mais elles réduisent aussi le temps disponible pour réparer une émission ou une publication défaillante à l’approche de l’expiration.

Un certificat long demande moins de renouvellements, au prix d’une plus longue persistance possible de l’ancien état. Un certificat court réduit cette persistance seulement si le remplacement et la récupération sont fiables. Il ne supprime pas le risque ; il en change la distribution.

Voilà pourquoi « pris en charge par le logiciel » ne suffit pas. Une mise en service vérifiable doit identifier le certificat de production, le début de la politique, le chevauchement éventuel, les contrôles du dépôt, la population de validation observée et la procédure appliquée si le prochain objet n’est pas disponible à temps.

Il n’est nullement nécessaire de publier une clé privée, l’architecture des HSM ou une procédure exploitable par un attaquant. Des dates, empreintes, classes de résultat et mesures agrégées suffisent.

Le bordereau minimal

La première rubrique doit définir la fonction : durée normale, avance de renouvellement, chevauchement autorisé, autorité d’exception et date de réexamen. Si « court » désigne une réduction relative, la durée de référence doit être nommée.

La deuxième rubrique décrit l’objet public : RIR émetteur, numéro de série, empreinte SHA-256, notBefore, notAfter, adresse du dépôt et confirmation de la correspondance avec la clé du TAL.

La troisième sépare les populations. Le dépôt faisant autorité a-t-il servi les octets attendus ? Un échantillon déclaré de validateurs a-t-il récupéré et accepté l’objet ? Que reste-t-il inconnu hors de l’échantillon ? Une observation partielle ne doit jamais être transformée en affirmation sur tous les validateurs d’Internet.

Les exceptions ont besoin d’un identifiant, d’un responsable, d’une classe de motif limitée, d’une échéance de révision et d’une condition de clôture. Leur existence peut être publique sans exposer les délibérations de sécurité.

Enfin, les corrections doivent s’ajouter à l’historique. Une empreinte erronée, une nouvelle émission ou une reclassification ne doit pas effacer l’ancien état. Une page réécrite sans version rend la prochaine analyse d’incident moins fiable que la précédente.

Une promesse commune, une exécution distribuée

Le programme NRO coordonne les cinq registres. Le NRO Executive Council parraine, un responsable de programme dirige les travaux, le Steering Group apporte l’orientation technique et les spécialistes des RIR exécutent. Cette coordination peut réduire des différences inutiles pour les opérateurs qui gèrent des ressources dans plusieurs régions.

Elle ne fait pas de la NRO l’opérateur de l’autorité de certification d’AFRINIC. AFRINIC émet et publie son matériel. Les relying parties entretiennent leurs ancres et leurs validateurs. Les réseaux décident comment utiliser les données validées. La coordination organise le travail ; elle ne réalise pas chaque acte.

La conclusion est donc bornée. Le certificat observable d’AFRINIC rend l’écart documentaire reproductible. Il ne prouve ni service RPKI défaillant, ni annonce trompeuse, ni dommage aux routes. Il montre que le public ne peut pas encore relier l’échéance de 2025 à un état de production AFRINIC accepté selon une définition stable.

La réparation est légère : une définition, un état par RIR, une date de preuve, une exception éventuelle et un historique conservé. L’ancre de confiance doit rester ennuyeuse. Son dossier de mise en service doit cesser d’être ambigu.

Sources