Résumé

  • RFC 9958 demande une agilité cryptographique et un inventaire des usages codés en dur comme des configurations exposées.
  • L’inventaire établit qu’un élément a été repéré ; il ne prouve ni sa sélection à l’exécution, ni la disparition des voies anciennes, ni la décision responsable sur le risque résiduel.

Dans une migration post-quantique, le tableau le plus rassurant est souvent celui qui mérite le plus de questions. Il rassemble des bibliothèques, des clés, des suites, des versions et des paramètres. Il finit alors par porter une étiquette : « prêt ». RFC 9958 propose quelque chose de plus modeste, et donc de plus solide. Le document demande aux développeurs de rechercher les algorithmes inscrits dans les applications et aux administrateurs, responsables de politiques et équipes de conformité de consigner les configurations cryptographiques que les applications exposent.

Ce travail donne une carte. Une carte n’est pas le trajet effectué. Une dépendance peut être présente sans être appelée ; une option peut être publiée sans être choisie par un pair ; une procédure de repli peut préserver une voie classique ; une configuration peut ne couvrir qu’un environnement secondaire. Même une observation d’exécution répond à une question bornée : elle montre un chemin, à un moment et dans un périmètre, pas tous les chemins de l’organisation ni toutes les données conservées.

La précision de RFC 9958 compte ici. La transition ne se réduit pas à remplacer un nom d’algorithme par un autre. Les tailles de clés, de chiffrés et de signatures, le coût de calcul et les interfaces changent. Le document distingue aussi les usages de cryptographie à clé publique des considérations propres aux symétriques et aux fonctions de hachage. Un KEM possède ses rôles d’encapsulation et de décapsulation ; noter « ML-KEM » dans un inventaire ne dit pas quel rôle il tient, quel protocole l’appelle, ni quelle donnée il protège.

Il faut donc empêcher l’inventaire de réunir des faits qui ne se ressemblent pas. Une fiche de découverte décrit comment un élément a été trouvé. Une fiche fonctionnelle décrit son emploi cryptographique. Une trace d’exécution associe un chemin réel à un moment d’observation. Une fiche de compatibilité documente le comportement d’un pair, d’un intermédiaire ou d’un ancien client. Une exception indique la voie conservée, son motif, son propriétaire et son échéance. Enfin, une décision identifie la personne ou l’instance qui autorise le changement, le report ou l’acceptation d’un risque.

Une seule ligne ne peut pas faire ce travail à la place de toutes les autres.

Ni RFC 9958 ni les spécifications NIST ne lui donnent ce pouvoir. RFC 9958 est un texte Informationnel, pas un certificat de déploiement ni une prédiction sur l’arrivée d’un ordinateur quantique cryptographiquement pertinent. FIPS 203 et FIPS 204 définissent ML-KEM et ML-DSA ; ils ne certifient pas le trafic d’une entreprise. De même, l’agilité décrite par RFC 7696 est une capacité de modification : elle ne démontre pas qu’une modification a été autorisée, propagée et observée sans effet indésirable.

La règle éditoriale de Heng Lu — privilégier le code qui s’exécute — évite le faux confort. Les déclarations et les configurations doivent être conservées, car elles rendent une enquête possible. Mais la preuve technique d’un chemin précis doit rester distincte, et la décision locale qui en tire une conséquence doit rester attribuable. Une organisation devient plus crédible lorsqu’elle peut dire « nous avons trouvé ceci, observé cela, décidé cela », plutôt que lorsqu’elle prononce un label totalisant.

Sources