Résumé

  • RFC 9935 définit trois représentations privées ML-KEM — graine, clé développée ou les deux — que le tag ASN.1 doit distinguer sans heuristique de longueur.
  • Avec les deux formes, le destinataire devrait régénérer la clé développée et comparer les octets ; s’il constate une divergence, il doit rejeter le paquet.

Une migration cryptographique peut échouer derrière un message « import réussi ». RFC 9935 montre pourquoi : comprendre la structure d’un fichier et établir la cohérence de son secret sont deux actes différents.

Pour les clés publiques, le texte fixe trois OID NIST, l’absence de paramètres dans AlgorithmIdentifier et des longueurs précises. Si l’extension keyUsage figure dans le certificat, seul keyEncipherment peut être marqué. Ces contraintes établissent une syntaxe et une intention déclarée. Elles ne prouvent ni la validation d’une chaîne, ni la possession de la clé privée, ni l’autorisation métier.

La partie privée propose seed, expandedKey et both. La graine de 64 octets permet de dériver de façon déterministe la clé de décapsulation et la clé publique. La forme développée stocke directement le secret plus volumineux. La forme combinée facilite l’échange entre systèmes qui conservent la graine et équipements qui ne comprennent que la clé développée.

Le tag [0], l’OCTET STRING ou la SEQUENCE identifient ces variantes. Une SEQUENCE correctement lue atteste la présence de deux champs ; elle ne dit pas qu’ils appartiennent à la même paire.

Pour le savoir, le destinataire devrait exécuter la dérivation normalisée à partir de la graine, puis comparer le résultat à la clé développée fournie. Il peut éviter ce coût, mais perd alors toute assurance de concordance. S’il effectue le contrôle et trouve des octets différents, RFC 9935 impose le rejet comme clé mal formée.

Le reçu doit donc séparer : structure analysée, variante reconnue, comparaison exécutée, comparaison réussie, import accepté et clé utilisée. Aucun état ne contient automatiquement le suivant.

Une seconde barrière vient de FIPS 203. Avant une décapsulation, la clé développée doit passer des contrôles de type, de longueur et de hachage interne. Le contrôle plus large d’une paire ajoute notamment la cohérence de la graine et un essai encapsulation-décapsulation. Même cet ensemble ne certifie pas que KeyGen a correctement produit la paire.

La conservation de la graine est un choix irréversible. On peut développer la clé depuis la graine ; après destruction de celle-ci, on ne peut pas la retrouver depuis la forme développée. La garder améliore portabilité et restauration, tout en maintenant un secret capable de recréer la paire. La supprimer ferme une voie d’export future.

RFC 5958 fournit le conteneur et RFC 9936 le chemin CMS voisin. Le contrôle local reste à prouver par un reçu sans octets secrets : empreinte du paquet, variante, versions de l’analyseur et du contrôle, résultat, décision et transformation éventuelle.

Sources