Résumé

  • Le rejet promis par rpki-client n’est pas arrivé comme un événement unique le 18 août : le commit du jour préparait la version 9.9, mais la branche concernée continuait d’avertir sans rejeter.
  • La dernière version portable publiée restait la 9.8 le 21 août ; parallèlement, une console rpki-client indépendante traitait des objets AFRINIC et signalait d’autres erreurs sans afficher l’ancien avertissement sur les noms X.509.
  • Les éléments décrivent une transition de compatibilité contrôlée, pas une bascule instantanée ni une panne. Avant de modifier une politique ROV, il faut lire séparément l’avis, le code, la version et le déploiement.

Une échéance est devenue quatre horloges opérationnelles

Une date précise donne l'impression d'un mécanisme précis. Ce n'est pas toujours le cas dans une infrastructure distribuée.

Le 19 février 2026, Job Snijders, mainteneur de rpki-client, avait averti le groupe de travail sur la base de données d'AFRINIC qu'à compter du mardi 18 août, le logiciel rejetterait les certificats dont les noms d'émetteur ou de sujet X.509 n'étaient pas encodés avec le type ASN.1 PrintableString. Le message mettait cette échéance en regard de l'objectif d'AFRINIC, fixé au 31 juillet, pour traiter les derniers objets concernés. L'avertissement public décrivait un risque de service RPKI pour les membres si le registre manquait son propre jalon.

Le 18 août, le dépôt amont a bien bougé. Un commit intitulé Prepare for rpki-client 9.9 release a remplacé le numéro 9.8 par 9.9. Mais ce changement de version ne constitue pas le durcissement annoncé. Dans la fonction valid_printable_string(), le type incorrect déclenche toujours un avertissement uniquement avec un niveau de verbosité élevé. Le return 0 qui provoquerait le rejet est encore neutralisé par #if 0 dans le code attaché à ce commit.

Au 21 août, la page des versions portables indiquait en outre que la 9.8, publiée en avril, restait la version la plus récente. Préparer un numéro dans le dépôt, publier une archive signée, intégrer un paquet dans une distribution et le déployer chez un opérateur sont quatre étapes distinctes.

Le 18 août n’était donc que l’horloge de l’avis. L’horloge du code avait changé de numéro sans activer le rejet ; celle de la version n’avait pas bougé ; celle du déploiement devait être lue dans des validateurs indépendants et des paquets aval.

Un validateur indépendant a montré la quatrième horloge

La console rpki-client indépendante fournit l’observation la plus utile du déploiement. Son exécution du 21 août montrait rpki-client -c -j en train de récupérer et de valider le dépôt mondial, y compris des objets AFRINIC. À partir de 08 h 33 UTC, elle a relevé des ruptures de séquence dans deux manifestes AFRINIC, puis deux ROA AFRINIC expirés.

Le journal ne masquait donc pas les erreurs. Il n’affichait pourtant plus l’ancien avertissement sur les noms d’émetteur ou de sujet non encodés en PrintableString. Cette observation est plus indépendante qu’un compte rendu de l’émetteur, mais elle reste l’absence d’un message dans le journal d’une implémentation, pas un recensement cryptographique de chaque certificat AFRINIC.

La conclusion défendable est donc opérationnelle, non triomphale. L’échéance est passée sans que la branche de rejet apparaisse dans le code épinglé, tandis qu’un validateur indépendant continuait à traiter les objets AFRINIC et exposait d’autres défauts. Ce tableau est compatible avec une réduction du stock hérité, sans établir la date de la dernière réémission ni l’accord de toutes les implémentations.

Une erreur de type simple, une migration qui ne l'était pas

Le défaut tenait à un choix d'encodage très circonscrit. La section 4.5 du RFC 6487 exige que l'attribut commonName des noms concernés soit encodé en PrintableString. Après une mise à niveau de son système RPKI en 2022, AFRINIC a produit ces valeurs en UTF8String.

Dans son explication de mars 2024, le registre a relié le comportement à une configuration OpenSSL mise à jour. La documentation laissait mal comprendre le masque appliqué par défaut. Une correction apportée à la documentation d'OpenSSL a précisé que utf8only était la valeur effectivement utilisée et que nombstr permettait de limiter l'encodage aux types compatibles avec PrintableString.

Corriger le chemin de signature suffisait pour les nouvelles émissions. Cela ne transformait pas les certificats et objets signés déjà publiés. Il fallait renouveler les clés des autorités de certification hébergées concernées, puis réémettre les objets dépendants. AFRINIC avait choisi de procéder par lots afin de réduire les risques d'incohérence aux points de publication et d'accorder un traitement particulier aux membres possédant de nombreux certificats de bout en bout.

C'est ici que l'histoire cesse d'être une querelle sur la conformité abstraite. Une règle peut tenir sur une ligne ; une migration sûre doit préserver une chaîne de publication vivante. AFRINIC maîtrisait la signature et la coordination avec les membres. Les mainteneurs du validateur maîtrisaient l'exception. Les opérateurs maîtrisaient l'adoption des versions. Aucune annonce isolée ne pouvait synchroniser ces trois plans.

Les 6 000 annonces constituaient un test de contrainte

En novembre 2025, la dette restait importante. Snijders indiquait alors 988 objets présentant un nom d'émetteur non conforme et 657 un nom de sujet non conforme. Il estimait qu'un retrait immédiat de l'exception aurait fait passer temporairement le nombre de VRP uniques sous le trust anchor AFRINIC de 21 027 à 19 480. Environ 6 000 annonces BGP auraient pu passer de l'état ROV valid à not-found jusqu'à la réémission des ROA. Les chiffres et leur hypothèse sont consignés dans l'archive DBWG.

Not-found ne signifie pas automatiquement invalid, et encore moins « inaccessible ». Cela signifie qu'une annonce ne bénéficie plus de la validation d'origine que lui procurait le VRP retiré. Le coût potentiel portait donc sur la couverture de sécurité, pas sur une panne universelle instantanée.

Surtout, ces valeurs décrivaient ce qui se serait produit si l'exception avait été supprimée à ce moment-là. Elles ne décrivent pas un incident observé en août 2026. Aucune source publique examinée pour cet article ne montre que 6 000 annonces ont effectivement changé d'état. Transformer une estimation conditionnelle en bilan d'incident serait une erreur factuelle — et masquerait ce qui ressemble plutôt à une migration réussie.

La bonne séquence réduit la dette sans déplacer le dommage

Le durcissement pouvait suivre deux ordres.

Dans le premier, le validateur retire d'abord sa tolérance. Les objets encore servis par le registre échouent, des VRP disparaissent temporairement et les détenteurs de ressources absorbent les conséquences d'une erreur qu'ils n'ont pas introduite dans le système de signature.

Dans le second, l'émetteur corrige le logiciel, renouvelle les autorités concernées, réémet les objets, puis démontre que la population problématique s'est épuisée. Le validateur peut ensuite appliquer la règle commune sans transformer le réseau en environnement de test.

Les signaux du 21 août correspondent davantage au second ordre. La console indépendante traitait les objets AFRINIC sans faire remonter l’ancien avertissement, tandis que la branche stricte restait inactive dans le code épinglé. C’est préférable à la situation inverse. Cela ne justifie pas de conserver éternellement une exception propre à AFRINIC : une telle divergence complique le code, les audits et la compréhension commune du profil RPKI.

L'échéance aura alors joué le rôle d'un mécanisme de coordination plutôt que celui d'un couperet logiciel. Elle a rendu explicite le coût du retard, concentré l'attention sur les derniers objets et créé une limite crédible à la tolérance. Le résultat opérationnel compte davantage que la fidélité littérale au calendrier.

Les limites de la preuve doivent rester visibles

Les sources consultées ne donnent pas la date exacte de la dernière réémission ni un rapport final détaillant toutes les autorités hébergées renouvelées. En janvier, une discussion citait le projet d'AFRINIC de publier des instructions, de contacter ses membres et d'ouvrir un service d'assistance, tandis que des participants relevaient l'absence de calendrier. Cet échange prouve l'intention de coordination, pas l'exécution complète de chaque mesure.

La console publique de rpki-client reste un seul point d’observation. Elle prouve qu’une exécution indépendante traitait des objets AFRINIC et signalait d’autres erreurs ; elle ne prouve pas que chaque objet était conforme ni que Routinator, Fort ou tous les paquets aval obtenaient le même résultat. Les ROA expirés et les ruptures de séquence des manifestes sont des problèmes distincts, sans lien établi avec l’ancien choix UTF8String.

Enfin, le dépôt amont n'est pas le parc installé. Un paquet peut intégrer un correctif différent, une distribution peut prendre du retard et un opérateur peut différer une mise à niveau. L'état doit donc être daté avec précision : la branche de rejet était encore désactivée dans le code du commit de version 9.9, et aucune version portable 9.9 n'était publiée au 21 août.

La conclusion demeure néanmoins solide : une échéance ne ferme pas une migration. L’analyse de Lu Heng sur la primauté du code en exécution fournit la bonne hiérarchie : un changement devient réel par l’implémentation, la validation, le déploiement et l’adoption. Le 21 août, ces quatre horloges décrivaient un écart de compatibilité géré, pas l’interrupteur unique promis en février.