Résumé

  • RFC 9640 normalise des types et groupements YANG réutilisables pour les mots de passe, clés, certificats, valeurs chiffrées et demandes de certificat.
  • Une valeur CMS bien formée et un algorithme acceptable ne démontrent ni la disponibilité ni la protection de la clé d’enveloppe.
  • Le reçu probant relie l’état du modèle à l’identité de session, à la décision NACM, à la cérémonie d’origine, au périmètre de garde, à l’usage effectif et à la fin de vie.

La sauvegarde contenait bien la valeur chiffrée. L’audit la déclara donc protégée et récupérable. Pourtant le chemin vers la clé d’enveloppe n’avait pas été capturé ; personne ne pouvait établir si cette clé existait encore, si elle était elle-même sauvegardée, ou si trop d’administrateurs pouvaient la mobiliser.

RFC 9640 rend cette limite visible. Son groupement de valeur chiffrée transporte notamment un format et un contenu CMS, mais son conteneur encrypted-by est vide. C’est au module consommateur de l’augmenter avec une référence vers la clé pertinente. Le standard offre la charnière ; il ne fabrique pas la chaîne de garde.

Une grammaire commune, pas un coffre complet

Publié sur la voie des normes en octobre 2024 par le groupe NETCONF de l’IETF, le module ietf-crypto-types rassemble identités, typedefs et groupements. Les typedefs encodent en DER des objets ASN.1 : demandes PKCS #10, certificats X.509, listes de révocation, réponses OCSP, structures CMS. Les groupements couvrent mots de passe, clés symétriques, clés publiques et privées, paires asymétriques, certificats et génération de CSR.

Cette base minimale évite à chaque modèle applicatif de réinventer les mêmes structures. Elle ne constitue pourtant ni un truststore ni un keystore complet. Les RFC 9641 et 9642 occupent ces territoires voisins. Des RPC génériques de génération de clés furent même retirés du travail initial, faute de consensus sur l’identification des algorithmes.

Une clé visible dans l’arbre atteste donc un état accepté par un serveur. Elle ne raconte pas nécessairement sa naissance : source d’aléa, politique d’algorithme, poste d’import, attestation du matériel, double contrôle ou première copie exportable. C’est précisément parce que RFC 9640 reste modulaire qu’un système local doit ajouter ces preuves.

Chiffrer crée une dépendance vérifiable

RFC 9640 permet des formes en clair, masquées et chiffrées lorsque les fonctions correspondantes sont activées. Le stockage en clair n’est pas recommandé. Les secrets lisibles reçoivent nacm:default-deny-all et les écritures sensibles nacm:default-deny-write. Une clé masquée demeure utilisable par le serveur tout en restant inaccessible par l’interface de gestion.

Pour le chiffrement symétrique, le RFC impose un mode convenable, tel qu’un AEAD ou CBC avec un vecteur d’initialisation aléatoire, et interdit ECB. Cette exigence écarte une faiblesse connue ; elle ne répond pas aux questions de garde. Quel objet exact a été chiffré ? Par quelle version de clé ? Le déchiffrement a-t-il été testé ? Quels acteurs peuvent le demander ? La rotation de la clé d’enveloppe ré-enveloppe-t-elle les anciennes valeurs ? Le plan de reprise conserve-t-il les deux côtés de la dépendance ?

La confidentialité, la disponibilité et la récupérabilité peuvent tirer dans des directions différentes. Dupliquer la clé d’enveloppe facilite la reprise mais élargit la surface d’accès. La rendre non exportable réduit certaines fuites mais exige un plan de remplacement du matériel. Un rapport honnête ne transforme pas le mot « chiffré » en verdict ; il expose ces arbitrages et la preuve choisie.

« Masquée » décrit une interface

La forme cachée dit que la valeur n’est pas accessible par les interfaces de gestion, tout en restant disponible au serveur. Elle ne promet ni résidence dans un HSM ni impossibilité d’export par toute autre voie. Un processus privilégié, une API locale, une image mémoire ou un journal mal conçu appartiennent à d’autres couches.

L’absence dans une réponse NETCONF est donc une observation utile et limitée. Pour revendiquer la non-extractibilité, il faut décrire le périmètre : matériel ou logiciel, version, politique d’objet, interfaces actives, rôle administrateur, fonctions de sauvegarde, mécanisme d’attestation et tests négatifs. Le vocabulaire du modèle ne doit pas absorber l’autorité de ces contrôles.

Le refus par défaut n’est pas l’historique

Les annotations NACM restrictives constituent un bon point de départ. Même les certificats méritent une protection, car leurs identifiants et métadonnées peuvent révéler des relations. Modifier une clé publique ou un certificat peut changer profondément la politique de confiance.

Mais une annotation ne prouve pas quelle règle fut chargée, quel principal fut authentifié, quelle exception s’appliqua ni si une autre interface contourna le chemin YANG. Un reçu d’accès doit conserver l’identité de la session NETCONF ou RESTCONF, le transport sécurisé, la version des règles NACM, la règle sélectionnée, l’opération, le chemin, l’état avant/après et le résultat du commit. L’approbation métier reste encore une décision distincte.

La cohérence mathématique a une portée précise

Lorsqu’une paire publique/privée est fournie, le serveur doit vérifier sa correspondance. Lorsqu’un certificat accompagne cette paire, sa clé publique doit correspondre. Ces contrôles empêchent une classe importante d’erreurs d’assemblage.

Ils ne prouvent pas que la clé privée a été produite selon la bonne politique, que l’autorité de certification a validé la bonne organisation, que le certificat n’est pas révoqué ni que l’application a utilisé cette clé. Les groupements génériques n’imposent d’ailleurs aucune finalité : signature, vérification, chiffrement et déchiffrement doivent être bornés par le module applicatif et la politique locale.

Même logique pour l’action de génération de CSR. Elle est protégée par default-deny-all, et RFC 9640 recommande une liaison de canal afin de rapprocher le demandeur applicatif de l’équipement authentifié au transport. Le CSR obtenu reste un objet de demande. Il faut encore tracer la soumission à l’autorité, l’approbation, le certificat émis, sa correspondance, son installation et son premier usage validé.

Supprimer un nœud n’efface pas automatiquement les traces

Le RFC indique que les clés en clair devraient être mises à zéro lors de leur suppression. C’est une exigence opérationnelle salutaire, pas son propre rapport d’exécution. La disparition du nœud démontre d’abord un changement de datastore.

Copies en mémoire, journaux, réplications, sauvegardes, swap, crash dumps et accélérateurs peuvent suivre d’autres calendriers. Une preuve d’effacement nomme l’implémentation, les domaines de stockage concernés, le mécanisme de destruction, la situation des répliques hors ligne, l’expiration des sauvegardes et la méthode de vérification. Si la certitude forensique est impossible, le système doit annoncer une conclusion plus étroite.

Relier le modèle à l’effet réel

Le reçu commence par la révision du module, les fonctions activées et le chemin de schéma. Il ajoute l’identité de la session, la liaison de canal, la règle NACM et l’approbation. Il conserve le changement de datastore et son identifiant de commit.

La fiche de la clé précise origine, génération ou import, algorithme, empreinte publique, périmètre de stockage, extractibilité, opérations permises et dépendance d’enveloppe. Une seconde trace documente chaque usage significatif : demandeur, autorisation, version, entrée, sortie, moteur et résultat. Rotation, révocation, sauvegarde et effacement ferment la boucle.

Ce montage respecte le rôle de chaque couche. YANG décrit. NETCONF ou RESTCONF transporte. NACM filtre. Le coffre conserve. Le moteur cryptographique agit. La gouvernance autorise. L’audit rapproche ces réalités sans prétendre qu’une seule remplace les autres.

Sources