Résumé

  • Le 4 septembre 2026, Rapport a séparé deux cas auparavant confondus : un certificat d’AC modifié et la même instance d’AC privée de son manifeste.
  • Dans le second cas, le script retire ca2.mft puis vérifie que six VRP restent présentes, dont deux reprises du cache de l’AC touchée.
  • Le commentaire exige une alerte, mais la commande qui devrait la contrôler est précédée de # et ne s’exécute pas.
  • La RFC 9286 distingue la continuité des objets en cache de l’avertissement motivé à l’opérateur. Une recette d’acceptation complète doit établir les deux.

Un test peut donner le bon résultat tout en ne contrôlant qu’une moitié du problème. C’est exactement ce que montre, sans qu’il soit nécessaire de spéculer sur un incident réel, le nouveau cas manifest-unreachable-fallback-to-cache de Rapport, le testeur de relying parties publié par LACNIC.

Le dispositif part d’un cache valide. Deux autorités de certification ont produit quatre VRP. Au cycle suivant, le générateur introduit une troisième AC, puis le script retire le manifeste de la deuxième du dépôt rsync. Le relying party est relancé. Le résultat attendu contient six VRP : deux de la première AC, deux de la troisième, mais aussi les deux de la deuxième qui doivent survivre grâce au cache précédent.

Juste avant cette vérification, le fichier contient une phrase sans ambiguïté : le validateur doit signaler l’absence du manifeste. La ligne suivante cherche un message de journal FORT. Or cette ligne est commentée. Dans un script POSIX, elle n’est pas une assertion en attente de résultat ; elle n’existe tout simplement pas à l’exécution.

Ce constat ne prouve pas que FORT garde le silence. Il ne dit rien non plus de Routinator, rpki-client ou rpki-prover. Il ne démontre ni une erreur de route, ni une faiblesse du dépôt de LACNIC, ni l’usage de Rapport en production. Il fixe seulement la portée du test public au commit c682fd2 : la continuité des VRP est contrôlée, l’avertissement mentionné par le commentaire ne l’est pas.

Conserver n’est pas dissimuler

La conservation du cache est ici une protection, pas un soupçon. Un manifeste RPKI est l’inventaire signé des certificats, de la liste de révocation et des objets signés liés au point de publication d’une autorité. Il sert notamment à détecter un objet retiré, remplacé en transit ou rejoué sous une version ancienne.

Quand l’acquisition du manifeste échoue, supprimer aussitôt tout ce qui avait été validé lors du cycle précédent peut créer une rupture artificielle. La RFC 9286 choisit une réponse plus prudente. Le traitement s’arrête pour l’instance d’AC concernée, mais le relying party devrait continuer d’utiliser les objets déjà mis en cache jusqu’à ce qu’ils deviennent périmés ou qu’un téléchargement réussi les remplace.

Cette règle limite deux erreurs symétriques : croire invalide une route qui reste autorisée, ou maintenir valide une route dont la preuve a réellement changé. Le cache offre du temps pour distinguer une panne de récupération passagère d’un nouvel état cryptographique. Le test de Rapport rend cette continuité mesurable en exigeant l’ensemble exact des VRP après l’échec.

Mais une continuité prudente n’est sûre que si elle est nommée. Pour le routeur, une VRP issue du dernier cycle réussi ressemble à une VRP obtenue à l’instant. Pour le centre d’exploitation, le nombre de routes peut rester stable. Le service paraît disponible alors que la fraîcheur de sa preuve vient de changer. C’est pourquoi la RFC ne traite pas l’alerte comme un détail d’interface : elle exige un avertissement indiquant la raison de l’arrêt du traitement pour cette instance d’AC et recommande d’en informer un humain.

Les deux obligations répondent à deux questions différentes. Quelles données le routeur reçoit-il ? Que sait l’opérateur de leur provenance actuelle ? La première peut réussir sans la seconde. Une alerte peut également apparaître alors que le mauvais jeu d’objets a été conservé. Les confondre transforme une propriété de sortie en certificat général de bonne gestion.

La séparation des scénarios est déjà un progrès

Le commit du 4 septembre est instructif parce qu’il remplace un cas trop large par deux situations où l’identité de l’AC change le résultat attendu.

Dans le scénario au SIA cassé, le certificat de l’AC est remplacé et son URI de manifeste pointe vers un emplacement inexistant. Les notes de suite considèrent qu’il s’agit d’une nouvelle instance d’AC sans cache antérieur applicable. Le script contrôle effectivement un diagnostic FORT et vérifie que les VRP de l’ancienne instance ne sont pas reprises, tandis que les AC sœurs continuent d’être traitées.

Dans le scénario de repli, le certificat, le SIA et le point de publication restent identiques. Seul le manifeste devient indisponible après un premier cycle réussi. Les objets du cache appartiennent toujours à la même instance. Ils doivent survivre, dans les limites de leur fraîcheur.

La RFC 9286 explique cette frontière. Plusieurs instances d’AC peuvent partager un point de publication, par exemple pendant un roulement de clés. Leurs manifestes n’en deviennent pas interchangeables. Le traitement est conduit séparément pour chaque instance, guidé par l’URI du manifeste inscrit dans le SIA du certificat de l’AC.

Rapport matérialise donc une distinction que les tableaux de bord réduisent souvent à « dépôt joignable » ou « dépôt indisponible ». L’unité pertinente est plus fine : quelle instance a échoué, quel succès précédent lui appartient, quels objets peuvent être repris, jusqu’à quand et avec quelle raison déclarée ?

Ne pas faire d’une phrase de journal une norme

La solution la plus rapide serait de décommenter la commande. Elle fournirait au moins une preuve pour la version de FORT visée. Ce serait utile, mais insuffisant comme contrat commun.

Les logiciels pris en charge n’exposent pas nécessairement le même événement sous la même forme. L’un écrit une phrase ; l’autre produit du JSON, une métrique ou un état interrogeable. Un changement de ponctuation peut casser un test littéral sans modifier le comportement. À l’inverse, une phrase familière peut être présente sans indiquer l’instance d’AC, le recours au cache ou l’âge des données.

L’assertion durable doit porter sur le sens : échec d’acquisition du manifeste, catégorie de raison, instance d’AC concernée, choix du repli sur cache, limite de fraîcheur, instant d’émission, nouvelle tentative prévue et état de notification humaine. Chaque adaptateur peut recueillir ces éléments sur la surface propre au produit. Rapport conserve alors une attente commune sans imposer le vocabulaire de FORT à tous les validateurs.

La vérification du cache mérite la même provenance. L’ensemble final des six VRP est nécessaire, mais une recette plus forte rattache les deux VRP conservées au cycle réussi précédent. Elle garde l’empreinte du certificat et du SIA, l’instant du dernier succès, l’empreinte du jeu d’objets, la cause de l’échec, le delta conservé, l’isolement des AC sœurs et la prochaine tentative.

Une recette à deux verdicts

Le résultat du test devrait afficher deux verdicts impossibles à fusionner.

Le verdict « état » répond à la question du contenu : instance d’AC correcte, cache admissible, objets encore frais, VRP attendues présentes, aucune VRP empruntée à une autre instance, traitement des sœurs intact. Le verdict « visibilité » répond à la question d’exploitation : avertissement motivé émis, événement rattaché à la bonne instance, décision de repli identifiable, âge du cache disponible, notification ou suppression volontaire consignée.

Si une implémentation ne rend pas l’un de ces éléments observable, le résultat doit dire « non testé » ou « non pris en charge », pas déduire un succès. L’honnêteté d’un test vient autant de ses limites que de ses coches vertes.

Cette distinction protège Rapport contre une utilisation qui dépasserait son statut. Le projet se présente comme un travail précoce et avertit que sa suite est encore bâtie autour de FORT. Une sortie peut servir au diagnostic entre développeurs sans devenir une certification universelle. La recette à deux verdicts transporte ce contexte vers les notes de version, les comparaisons de produits ou les décisions d’exploitation où le terminal d’origine n’est plus visible.

L’alerte doit raconter une durée, pas produire du bruit

Une alerte par interrogation ratée serait vite ignorée. Le contrat sémantique peut être plus sobre : ouvrir un événement pour l’instance et l’épisode concernés, mettre à jour sa durée et l’âge du cache lors des échecs suivants, puis fermer le même événement lorsqu’un téléchargement réussi remplace les données. L’opérateur obtient une histoire : début, état conservé, tentatives, seuil de fraîcheur, récupération.

Cette histoire est le complément naturel de la stabilité. Tant que les VRP restent correctes, il n’y a pas lieu de fabriquer une crise. Tant que le manifeste demeure indisponible, il n’y a pas lieu de qualifier le système de pleinement sain. L’état exact est « service sur cache validé après échec de récupération », avec un propriétaire et une échéance.

Le commentaire de Rapport a déjà trouvé la bonne obligation. Le script a déjà trouvé le bon jeu de routes. La prochaine étape n’est pas de choisir entre les deux, mais de les faire réussir séparément dans la même preuve.

Sources