Résumé

  • RFC 9642 normalise un keystore YANG pour clés symétriques et asymétriques, certificats, références centrales et définitions intégrées ; il ne certifie pas la reprise opérationnelle.
  • La portabilité des objets chiffrés dépend du KEK partagé, des clés primaires propres aux serveurs, de l’opération de réenveloppement et de la fermeture complète du graphe de dépendances.
  • Un reçu de reprise relie sauvegarde, origines de datastore et contrôles d’accès aux consommateurs, aux opérations cryptographiques, à la rotation des certificats et à l’effet de service observé.

Six services pointaient vers la même clé centrale. L’équipe de migration recopia le keystore sur le nouvel équipement et vérifia que toutes les leafrefs se résolvaient. Elle conclut que les six identités avaient migré.

Pourtant, deux services continuaient d’utiliser une définition intégrée restée dans leur propre configuration. Un troisième résolvait bien la clé centrale, mais son certificat actif appartenait encore à l’ancienne paire. La centralisation avait simplifié l’inventaire ; elle n’avait pas prouvé l’attachement effectif.

RFC 9642 crée ietf-keystore, un vocabulaire commun pour les clés symétriques et asymétriques, leurs certificats, les valeurs cachées ou chiffrées et les références utilisées par d’autres modèles. Sa force est de coordonner des implémentations autonomes. Sa limite est tout aussi importante : l’arbre décrit un état de gestion, pas le déroulement complet d’une reprise.

Une référence centrale organise le changement, elle ne constate pas l’usage

Les fonctionnalités de RFC 9642 séparent keystore central, définitions intégrées, clés asymétriques et clés symétriques. Un consommateur peut offrir un choix entre matériel local et référence centrale ; d’autres emplacements peuvent être ajoutés par augmentation. Deux serveurs annonçant le même RFC peuvent donc exposer des surfaces différentes.

Le nom d’une clé centrale n’est ni un identifiant mondial ni une preuve d’identité matérielle. Le reçu doit conserver la révision du module, les fonctionnalités, le chemin exact, le contexte de schéma, le hash de l’objet et le modèle consommateur. Lors d’un changement central, il faut dresser la liste des références attendues et observer celles qui sont réellement résolues au moment de l’opération.

Cette distinction évite deux erreurs opposées. La première suppose qu’un changement central atteint automatiquement tous les services. La seconde suppose que deux définitions contenant les mêmes octets ont le même propriétaire et évolueront ensemble. Une valeur intégrée peut diverger demain ; une référence centrale peut changer sans modification locale.

L’origine système ne raconte pas la fabrication

Conforme à RFC 8342, le modèle distingue la configuration voulue et l’état opérationnel. Une clé fournie par le serveur peut apparaître avec une origine système. Elle peut avoir été installée en usine, créée au premier démarrage ou générée à l’activation d’un service.

L’annotation dit que la valeur vient du système et non d’une écriture ordinaire de l’opérateur. Elle ne dit pas qui l’a produite, où réside la partie privée, si elle est exportable, quel micrologiciel l’a introduite ni si le certificat d’identité joint reste valable. La procédure du fournisseur et la modification de ces clés sont hors périmètre du RFC.

Lorsqu’une clé intégrée reçoit ensuite un certificat de déploiement ajouté par l’opérateur, les deux origines coexistent. Une projection qui les aplatit sous l’étiquette « clé configurée » détruit précisément la frontière dont dépend l’enquête. Le reçu conserve l’origine de la clé, celle de chaque certificat et l’acte qui les a associés.

Le graphe de chiffrement est une partie de la sauvegarde

Une clé chiffrée contient un format, une valeur chiffrée et une référence vers la clé qui la protège. Ce lien encrypted-by est une dépendance exécutable. Le serveur doit disposer du KEK ou d’une API capable de l’utiliser ; sinon le nœud est intact mais inerte.

RFC 9642 décrit, à titre non normatif, une migration où de nombreuses clés sont chiffrées sous un KEK partagé. Ce KEK est lui-même protégé par une clé primaire propre au serveur. Pour restaurer ailleurs, on réenveloppe le KEK partagé sous la clé primaire du serveur cible ; les nombreux autres chiffrés peuvent rester identiques.

La somme de contrôle d’une archive ne mesure donc pas sa restaurabilité. Il faut vérifier la fermeture du graphe : objets chiffrés, arêtes vers le KEK, disponibilité de l’ancienne et de la nouvelle autorité, formats, algorithmes, identité du serveur cible, autorisation du réenveloppement et résultat. Le KEK partagé réduit le travail, mais agrandit aussi le rayon d’impact d’une indisponibilité, d’une substitution ou d’un accès excessif.

« Caché » et « chiffré » restent des affirmations bornées

RFC 9640 fournit les formes cryptographiques reprises par le keystore. Une clé cachée n’est pas renvoyée par la surface de gestion représentée ; cela ne suffit pas à conclure qu’aucune autre interface ne peut l’extraire. Une valeur chiffrée ne prouve ni la protection du KEK ni sa disponibilité après sinistre.

RFC 9642 recommande le chiffrement des contenus persistants et la mise à zéro des copies déchiffrées en mémoire volatile lorsqu’elles ne servent plus. Si la persistance n’est pas chiffrée, elle doit être inaccessible. Ces exigences guident l’implémentation ; le modèle ne mesure pas les répliques, journaux, crash dumps, sauvegardes secondaires ou privilèges locaux.

Le dossier de reprise ajoute donc des preuves propres au système : couverture du chiffrement, rôles, journaux d’accès, politique mémoire, tests négatifs, inventaire des copies et destruction. Il n’élargit jamais « absent d’une réponse NETCONF » en « inextrait partout ».

NACM protège l’interface, pas toute l’histoire

Les nœuds modifiables du module portent nacm:default-deny-write, et les secrets lisibles héritent de protections fortes. RFC 8341 établit le mécanisme de décision. L’étiquette ne conserve pas la session qui a été jugée.

Une preuve de changement relie l’identité NETCONF ou RESTCONF, le canal, la version de politique, la règle appliquée, le chemin, l’avant/après, le commit, l’approbation et la projection opérationnelle. Elle nomme aussi les interfaces locales, matérielles ou fournisseur qui échappent à YANG. RFC 6241 et RFC 8040 donnent le contexte de gestion ; ils ne remplacent pas ce journal.

RFC 9642 ne définit ni RPC ni action. La génération peut venir des modèles SSH/TLS ou d’une opération externe menée par un responsable cryptographique. La présence finale de la clé ne permet pas de reconstruire cette cérémonie sans reçu séparé.

Certificat associé ne veut pas dire service activé

Une clé asymétrique peut porter plusieurs certificats. Un consommateur peut référencer la clé seule, l’ensemble clé-certificats ou une paire certificat final–clé. L’errata vérifié 8441 corrige un commentaire copié qui parlait à tort d’une clé symétrique ; la structure normative désigne bien une paire asymétrique et certificat.

L’association ne prouve pas la sélection par le service. Les modèles de RFC 9644 et RFC 9645 peuvent consommer le keystore pour SSH et TLS. Le reçu résout la référence de chaque service, fixe sa version de configuration, observe l’opération de clé et rattache la session ou le résultat au bon objet.

Le RFC ne limite pas non plus l’usage d’une clé privée à la signature ou au déchiffrement. Les contraintes du certificat portent sur la clé publique associée ; mandat organisationnel et opération réellement exécutée restent distincts. Un test de reprise doit réussir l’usage prévu et refuser ceux qui ne le sont pas.

La notification d’expiration ouvre une tâche

L’événement d’expiration signale une date. Il ne prouve pas la livraison, l’acquittement, le remplacement, l’association au bon objet, la mise à jour des consommateurs ni le succès après rotation. Une vieille sauvegarde peut même réintroduire un certificat déjà remplacé.

Le reçu suit l’événement jusqu’au destinataire, à l’objet neuf, au contrôle de correspondance, à la référence active et à l’opération observée. Il garde les branches divergentes : keystore central à jour, service intégré ancien ; certificat neuf présent, service encore lié à l’ancien.

Prouver la reprise

On commence par le hash de la sauvegarde, le serveur source, les datastores, le schéma, les fonctionnalités et toutes les origines. On préserve les empreintes des clés et certificats, les formats et chaque arête encrypted-by. Puis on nomme les deux clés primaires, le KEK partagé, l’acteur autorisé et le résultat du réenveloppement.

Sur la cible, on teste l’ouverture des objets requis, la résolution des références centrales et intégrées, l’association des certificats, le choix de chaque consommateur, l’opération attendue et le refus des usages interdits. Enfin on observe l’effet borné du service et sa capacité de retour arrière.

La leçon de la spécification minimale est respectée : RFC 9642 coordonne le vocabulaire et la structure. Le code en cours d’exécution exerce l’autorité cryptographique. La reprise n’est prouvée qu’au point où les deux sont reliés par des faits conservés.

Sources