Résumé

  • RFC 9641 définit des sacs nommés de certificats et de clés publiques, réutilisables par référence centrale ou sous forme intégrée ; il ne consigne pas une authentification achevée.
  • Une modification centrale peut corriger plusieurs consommateurs à la fois ou élargir silencieusement leur surface d’acceptation ; le reçu doit figer les octets et la version réellement résolus.
  • La preuve complète relie l’origine de configuration au pair présenté, au chemin, à l’horloge, au nom de service, à l’usage, à la révocation, au verdict du vérificateur et à l’autorisation ultérieure.

Le changement paraissait minuscule : remplacer un certificat dans le sac central production-server-anchors. Aucun fichier de configuration de service n’avait été touché. Pourtant, six clients TLS venaient d’acquérir une nouvelle possibilité d’acceptation, chacun selon ses propres règles de nom, d’usage et d’autorisation.

C’est le principal avantage opérationnel d’un truststore central, et son principal risque. La référence évite de recopier le même matériel partout. Elle ne réduit pas la portée du changement ; elle la rend indirecte. Un audit qui ne regarde que les différences dans la configuration de chaque client peut donc conclure, à tort, qu’aucune frontière de confiance n’a bougé.

RFC 9641 fournit le modèle ietf-truststore pour rendre cette relation explicite. Il organise des certificats et des clés publiques brutes en sacs nommés et offre des groupements permettant à un modèle consommateur de choisir une définition intégrée ou une référence centrale. La norme décrit avec précision l’entrée de configuration. Elle laisse, à juste titre, au consommateur la validation de l’identité et la décision d’usage.

Un sac décrit une intention, pas un verdict

Publié sur la voie des normes en octobre 2024 par le groupe NETCONF de l’IETF, RFC 9641 demande que les sacs rassemblent des objets destinés à un objectif commun. L’objectif d’un sac de certificats devrait être décrit ; celui d’un sac de clés publiques doit l’être. Cette description aide l’opérateur à comprendre la délégation. Elle ne transforme pas un texte en contrainte exécutée.

Le modèle générique ne limite pas, à lui seul, les noms, les chemins de certification ou les opérations autorisées. Une ancre est implicitement fiable pour construire des chemins pouvant porter n’importe quel nom et servir n’importe quel objectif, sauf si le contexte consommateur ou une politique auxiliaire impose des limites. Les groupements TLS de RFC 9645, par exemple, donnent un emplacement d’usage, mais le déploiement doit toujours révéler les contrôles réellement appliqués.

Le reçu ne peut donc pas reprendre le nom « serveurs de production » comme résultat. Il doit montrer quel consommateur a sélectionné le sac, quel objet il a résolu et quelles règles ont rejeté ou accepté le pair. Pour une clé publique brute, la logique n’est pas celle d’un chemin X.509. Pour un certificat, la validité du chemin ne répond pas encore à la question du nom de service.

Les mêmes octets n’ont pas le même avenir

Une ancre intégrée dans un service et une ancre référencée depuis le truststore peuvent être identiques aujourd’hui. Leur empreinte peut coïncider bit pour bit. Leur gouvernance future diffère néanmoins.

La référence centrale confie la mise à jour à un propriétaire commun. Elle permet de retirer rapidement un objet compromis ou de déployer une nouvelle chaîne. En contrepartie, une erreur centrale peut atteindre tous les consommateurs. La définition intégrée limite la portée d’une modification, mais elle se périme facilement : des instances restent hors ligne, des équipes appliquent des calendriers différents et les exceptions deviennent permanentes.

Il n’existe donc pas de victoire abstraite de la centralisation sur l’intégration. Il existe un choix entre deux surfaces de contrôle. Pour le rendre vérifiable, il faut conserver le nom du sac, l’identifiant de l’objet, ses octets ou son empreinte, son origine de datastore, sa version ou son condensat, le chemin de configuration consommateur, l’heure de résolution et la liste des services exposés au changement.

Un nom mutable ne peut pas servir de preuve historique. Après deux rotations, « le client utilisait production-server-anchors » ne dit plus quelle ancre a participé à l’événement. La preuve doit quitter le symbole et rejoindre l’objet exécuté.

L’origine système ne raconte pas la fabrication

Certains équipements embarquent des ancres pour les services du constructeur, l’amorçage sécurisé ou des autorités publiques. RFC 9641 prévoit leur présence dans l’état opérationnel et, lorsque le datastore système existe, dans cet état système, avec une origine system distincte de la configuration voulue par l’opérateur.

Cette distinction protège l’attribution : une ancre fournie par le constructeur ne doit pas apparaître comme un choix local. Mais l’origine système n’est pas une chaîne de provenance. La méthode d’installation ou de modification de ces ancres reste propre à l’implémentation. La vue opérationnelle ne prouve ni la garde en usine, ni l’autorisation de la mise à jour, ni la version du logiciel qui a introduit l’objet.

Le cas de l’amorçage sécurisé de RFC 8572 montre l’enjeu. Une confiance initiale peut déterminer quel contrôleur obtiendra ensuite le pouvoir de configurer l’équipement. Confondre l’origine système, la présence opérationnelle et l’usage réel supprime les frontières dont l’enquête a besoin.

NACM protège l’interface, pas tous les chemins d’écriture

Les nœuds et références du truststore portent nacm:default-deny-write. Selon RFC 8341, un changement commence donc par être refusé, sauf règle plus précise. C’est indispensable : même un certificat public peut déplacer la frontière d’acceptation.

Cette valeur par défaut ne constitue toutefois ni une approbation métier ni un journal d’exécution. Il faut relier l’identité de session NETCONF ou RESTCONF, le canal sécurisé, la version des règles NACM, la règle retenue, l’opération et le chemin demandés, les valeurs avant et après, le commit et la projection opérationnelle. L’architecture NMDA de RFC 8342 distingue les réalités de datastore ; elle ne les fusionne pas.

RFC 9641 précise aussi que YANG ne peut pas imposer la protection au repos. L’API sécurisée et NACM gouvernent l’accès par le plan de gestion. Un compte privilégié local, un paquet logiciel, une base corrompue ou une restauration de sauvegarde peuvent suivre un autre chemin. L’implémentation doit protéger le contenu stocké, et l’audit doit en apporter une preuve distincte.

L’alerte d’expiration n’est pas le remplacement

La fonctionnalité de notification peut signaler qu’un certificat approche de son expiration ou l’a atteinte. Ce signal est utile, mais il ne prouve pas qu’un abonné l’a reçu, qu’un responsable l’a reconnu, qu’une nouvelle ancre a été approuvée ni que tous les consommateurs l’emploient.

Le reçu d’expiration doit relier la fonctionnalité activée, l’abonnement, l’événement, sa livraison, son acquittement, l’objet de remplacement, la mise à jour des références et la prochaine validation réussie. Il doit aussi conserver les divergences : le truststore central peut être à jour alors qu’un consommateur intégré reste ancien ; un certificat non expiré peut échouer sur le nom, l’usage ou la révocation.

De la chaîne valide à l’action autorisée

RFC 5280 définit la validation des chemins X.509. Le vérificateur doit encore choisir un chemin candidat, traiter les contraintes et appliquer la politique locale. RFC 6125 exige de séparer l’identité du service de la simple validité cryptographique du chemin. TLS 1.3 donne le contexte de session où ces objets sont présentés.

Pour un événement précis, il faut conserver le certificat ou la clé du pair, l’identifiant de session, les octets exacts de l’ancre, le chemin candidat et celui retenu, l’heure et la source d’horloge, les périodes de validité, le nom de référence, la règle de correspondance, les usages de clé, les contraintes de nom, les politiques, les algorithmes, l’état de révocation exigé, la version du vérificateur et son motif final.

Puis vient une décision supplémentaire. Un pair authentifié n’est pas nécessairement autorisé à effectuer l’opération demandée. La lecture d’une télémétrie et la modification d’une politique de routage n’ont pas le même mandat. L’autorisation doit être enregistrée après l’authentification, et non absorbée dans le mot « confiance ».

Construire le reçu d’acceptation

Le reçu commence par la révision du module, les fonctionnalités activées et le chemin exact. Il nomme le mode intégré, central ou incorporé au système, l’origine voulue, système et opérationnelle, l’auteur du changement et la preuve d’intégrité au repos.

Au moment de l’usage, il fige les octets résolus, le consommateur, le pair, le chemin, le temps, le nom, l’objectif, la politique et le résultat. Une modification centrale déclenche un inventaire des consommateurs et une comparaison avant/après. Une alerte d’expiration reste ouverte jusqu’à l’acquittement, au remplacement et à l’usage vérifié.

Ce dispositif respecte la leçon de la spécification minimale : un vocabulaire partagé peut coordonner des systèmes autonomes sans prétendre gouverner toutes leurs décisions. RFC 9641 nomme l’entrée commune. Le code en cours d’exécution décide localement. Le reçu empêche que ces deux réalités soient confondues.

Sources