Résumé

  • L’extension CRL Number reste obligatoire, mais le RP doit ignorer sa valeur pour ordonner les CRL ; il n’en contrôle que le caractère non critique et l’entier borné non négatif.
  • La CRL applicable est l’unique objet à la fois désigné par le CRLDP du certificat et inscrit, avec une empreinte concordante, dans le manifeste courant de l’émetteur.
  • Ce choix ne prouve ni l’absence de révocation, ni la validité d’un objet signé, ni l’autorisation d’une route, ni son passage dans le plan de données.

Le voyant vert suivait le mauvais compteur

Imaginons un pupitre d’exploitation qui compare deux CRL correctement signées. La première porte le numéro 418 ; la seconde, 417. L’interface colore 418 en vert. Mais le manifeste courant nomme la seconde et engage l’empreinte de ses octets ; le CRLDP du certificat pointe vers elle aussi. Le pupitre a comparé une valeur réelle et tiré une conclusion interdite.

Ce scénario est construit. Il n’attribue ce comportement à aucun produit. RFC 9829 corrige justement la règle : dans la RPKI, la grandeur de CRL Number n’élit pas la CRL courante. La fiche RFC Editor et la fiche Datatracker situent ce RFC Standards Track de juillet 2025, qui met à jour RFC 6487. Son historique, ses références, les documents qui le citent et la recherche d’errata documentent le texte, pas son déploiement. Aucun erratum correspondant n’était enregistré au gel des sources.

RFC 5280 explique pourquoi le réflexe paraît raisonnable. Dans une PKI où plusieurs CRL utilisables peuvent coexister, CRL Number est une séquence croissante qui aide à déterminer laquelle en remplace une autre. La RPKI réduit ce choix en amont. RFC 6481 structure le dépôt d’une autorité ; RFC 9286 fait du manifeste signé l’inventaire des objets courants, avec pour chacun nom de fichier et empreinte. Cet inventaire contient une seule CRL courante de la CA.

Le numéro n’est donc pas mensonger. Il est redondant comme source de décision.

Une extension obligatoire peut perdre son pouvoir

RFC 9829 conserve exactement deux extensions dans chaque CRL RPKI : Authority Key Identifier et CRL Number. Le RP traite l’AKI. Pour CRL Number, il vérifie seulement que l’extension n’est pas critique et que la valeur est un entier non négatif inférieur ou égal à 2^159-1. Ensuite, il ignore cette valeur pour le classement.

Présence, bonne syntaxe et autorité sont trois propriétés différentes. Confondre les trois revient à donner à tout champ validé le droit de gouverner le processus qui suit.

Le RFC recommande de faire coïncider CRL Number avec le manifestNumber du manifeste qui inclura la CRL. Cette égalité facilite le diagnostic. Elle n’installe pas un mécanisme de secours « plus grand numéro gagne ». En cas d’écart, le RP ne reçoit aucune permission d’abandonner le manifeste.

Le bon tableau de bord montre donc plusieurs reçus : extension présente, syntaxe admise, manifeste sélectionné, objet engagé, CRLDP concordant. Un badge unique « CRL valide » cache l’endroit où le système a décidé.

L’autorité naît d’une intersection

RFC 6487 définit le profil des certificats de ressources et l’extension CRL Distribution Points. RFC 9829 modifie son étape de validation : la CRL courante pertinente doit être identifiée à la fois par le manifeste courant de l’émetteur et par le CRLDP du certificat.

Le CRLDP seul donne un emplacement, sans démontrer que les octets appartiennent à la publication courante. Le manifeste seul engage une CRL de la CA, sans établir qu’un certificat donné désigne cet objet. Le nom sans l’empreinte permettrait une substitution. L’empreinte sous un manifeste non validé ne porte aucune autorité vérifiée. Les preuves doivent se rencontrer.

Le manifestNumber reste, lui, une donnée d’ordre. RFC 9286 demande à l’émetteur de l’augmenter et au RP de comparer les nouveaux manifestes aux précédents, avec leurs temps thisUpdate et nextUpdate. C’est cet ordre de manifestes qui absorbe la fonction autrefois prêtée à CRL Number.

Cette mécanique ne répète pas l’article RFC 9981 sur l’épuisement du numéro de manifeste et le changement de nom qui ouvre une nouvelle époque de comparaison. Ici, la question est différente : une fois le manifeste courant établi, quel signal peut choisir sa CRL ?

Une empreinte engage des octets, pas le monde

RFC 9286 permet de détecter retrait, substitution ancienne ou modification d’objets. RFC 9829 décrit l’empreinte du manifeste comme une garantie cryptographique de l’intention de la CA quant à sa CRL la plus récente et comme un moyen de retirer certains vecteurs de rejeu.

L’intention a une portée. Une empreinte concordante prouve que les octets récupérés sont ceux engagés par le manifeste validé. Elle ne rend pas ce manifeste frais ; ne valide pas la signature de la CRL ; ne prouve pas la relation de clé ; ne décide pas si le numéro de série du certificat figure dans la liste ; et ne produit aucune route.

La CRL doit encore être valide. La clé publique qui vérifie sa signature doit être celle qui vérifie le certificat. La révocation est établie par la présence du numéro de série sur cette CRL applicable. RFC 3779 encadre les extensions de ressources IP et ASN, mais une chaîne de certificats réussie ne décrit pas l’état instantané d’une annonce BGP.

Le transport multiplie les vues

RFC 8182 définit RRDP ; rsync constitue une autre voie de récupération connue. Recevoir des octets ne les rend pas courants. Les RP gardent des caches et peuvent observer des époques différentes. L’audit doit donc demander quel manifeste validé, quelle règle de cache et quelle empreinte ont été utilisés, non quel numéro de CRL semblait le plus récent.

L’article antérieur sur RFC 9589 garde son sujet : signing-time, mod-time et contrôle rapide lors d’un passage RRDP–rsync. Il citait RFC 9829 pour empêcher qu’une date de fichier choisisse la CRL. Le présent texte ouvre le mécanisme laissé en soutien : la suppression volontaire d’un second oracle d’ordre.

Après la décision de révocation viennent encore d’autres couches. RFC 6811 associe données d’origine validées et route BGP pour produire un état local. RFC 8210 transporte des données validées vers les routeurs. La réception, la politique locale, le RIB, le FIB et le trafic observé exigent chacun une preuve.

Une chaîne d’audit exploitable conserve : publication CA ; transport du dépôt ; sélection et validation du manifeste ; rencontre CRLDP/nom/empreinte ; validation de la CRL ; recherche du numéro de série ; validation de l’objet signé ; calcul d’origine ; reçu du routeur ; action de politique ; observation du trafic.

Retirer un oracle est une décision d’architecture

RFC 9829 réduit la surface commune au lieu de l’épaissir. Il garde un champ nécessaire au profil X.509 mais lui refuse un pouvoir devenu inutile. Minimum Initial Specification de Heng Lu éclaire cette discipline : partager l’invariant minimal sans transformer chaque symbole en centre de gouvernement. Reality Layers sépare compteur, manifeste, octets, décision et résultat. Running-Code Primacy exige enfin la preuve que le validateur et le routeur ont réellement suivi ce modèle.

Le test décisif place volontairement le plus grand CRL Number sur l’objet absent du manifeste courant. Le RP doit choisir l’autre, puis exposer séparément les échecs d’empreinte, de fraîcheur, de signature, de clé et de recherche du numéro de série. Si le résultat ne donne qu’un booléen, il ne prouve pas l’algorithme.

Sources