Résumé

  • Dans KEMRecipientInfo, rid identifie le certificat ou la clé publique du destinataire, kem l’algorithme et kemct le chiffré produit pour lui.
  • Ce sont des faits sur une construction CMS. Ils ne prouvent ni possession de la clé de décapsulation, ni traitement local réussi, ni lecture, ni autorisation organisationnelle.

Le dossier de messagerie peut sembler concluant : un destinataire est nommé, l’algorithme ML-KEM est visible, et un chiffré lui est associé. Pourtant, le dossier ne contient pas une preuve d’ouverture.

La fonction de RFC 9936 est plus étroite et plus utile que cette conclusion. Le texte fixe l’usage de ML-KEM-512, -768 et -1024 dans CMS via KEMRecipientInfo. Avec la clé publique d’encapsulation du destinataire, l’émetteur produit un chiffré et un secret partagé. Avec sa clé privée de décapsulation et ce chiffré, le destinataire produit le secret correspondant. La construction sert à transférer une clé de chiffrement de contenu.

Il est donc possible d’inspecter une voie cryptographique destinée à une clé. Il n’est pas possible, par cette seule inspection, d’affirmer qui détenait la clé privée, si la décapsulation a abouti, si le contenu a passé les contrôles locaux ou si une procédure a accepté son instruction.

Le certificat place une clé publique, pas une action

RFC 9936 exige OtherRecipientInfo avec KEMRecipientInfo pour ce destinataire. rid identifie le certificat ou la clé publique; kem choisit l’un des identifiants ML-KEM; kemct est le chiffré de ce destinataire. Les champs de dérivation et d’enveloppement servent aussi au chemin de transfert de clé.

La RFC indique que l’émetteur obtient la clé publique statique du certificat du destinataire, selon les conventions de RFC 9935. C’est une information de distribution de clé. Ce n’est pas une attestation datée de la garde de sa contrepartie privée, de l’accès autorisé à un module, ni de l’identité de l’opérateur qui a employé cette clé.

Une annonce SMIMECapabilities demande la même prudence. Elle peut annoncer une liste partielle d’algorithmes qu’une implémentation sait prendre en charge. Une capacité annoncée n’est pas une preuve d’emploi dans ce message; un emploi encodé n’est pas une preuve de décapsulation; une décapsulation n’est pas un reçu de lecture ou d’approbation.

Les faits décisifs restent locaux

La séparation est inscrite dans les fonctions. Encapsulate reçoit la clé publique et produit chiffré et secret de l’émetteur. Decapsulate reçoit la clé privée et le chiffré et produit le secret du destinataire. La RFC impose ces fonctions aux rôles CMS, sans créer de journal public de la personne ou du service qui a utilisé la clé.

Les règles de sécurité ne comblent pas ce manque de preuve. Elles imposent la protection de la clé privée ML-KEM et des clés associées, l’effacement des clés éphémères et une bonne production d’aléa. Un objet CMS bien formé ne démontre pas que ces obligations ont été respectées dans une installation donnée.

La discipline de Heng Lu est pertinente comme limite de lecture : le fait partagé doit rester ce qu’un tiers peut vérifier dans l’objet. Un identifiant publié ne devient pas, par récit, une réalité d’exécution. Conserver cette frontière protège à la fois l’utilité du format et la qualité de l’audit.

Une chaîne de preuve, et non une étiquette plus large

Conservez l’objet CMS, rid, l’algorithme, le chiffré, la dérivation, l’enveloppement, l’instant d’observation et le résultat de validation du certificat. Gardez séparément les preuves de garde de clé, de décapsulation et d’acceptation applicative. Si une décision compte, conservez aussi la délégation, la règle et l’approbation qui l’autorisent. Chaque enregistrement doit répondre à sa propre question.

Sources