Résumé

  • Le 18 septembre 2026, l’IESG a approuvé draft-ietf-lamps-cms-composite-kem-03 comme Proposed Standard. Le Datatracker indique désormais RFC Ed Queue, mais le RFC Editor affiche blocked: Reference Not Received. L’action IANA est In Progress et l’examen IANA reste IANA OK - Actions Needed. Le document n’est donc pas encore un RFC publié.
  • Le document CMS est un compagnon de draft-ietf-lamps-pq-composite-kem-21, qu’il cite comme référence normative. Cette dépendance reste à l’état IESG Evaluation::Revised I-D Needed, avec deux positions DISCUSS et des actions IANA encore nécessaires.
  • La dépendance fournit les opérations KeyGen, Encaps et Decaps, les conventions permettant de transporter les clés Composite ML-KEM dans les certificats X.509 et les identifiants d’algorithmes. Le document CMS ajoute les règles propres à KEMRecipientInfo, à l’usage de ces certificats et à SMIMECapabilities.
  • L’approbation IESG, l’entrée dans la file du RFC Editor, les allocations IANA, la disponibilité d’une implémentation, l’interopérabilité entre deux logiciels et l’activation en production sont des états distincts. Pour les gouverner correctement, les opérateurs ont besoin d’un reçu de dépendance qui enregistre précisément ce qui a été normalisé, testé et autorisé.

L’événement : une approbation réelle, mais pas une publication RFC

L’annonce du 18 septembre 2026 marque une étape formelle : l’IESG a approuvé draft-ietf-lamps-cms-composite-kem-03, « Composite ML-KEM for use in Cryptographic Message Syntax (CMS) », comme Proposed Standard. Le document a donc franchi son contrôle IESG et est entré dans la phase de production qui suit cette approbation.

Il serait toutefois incorrect de présenter cette décision comme la publication d’un RFC. Le Datatracker conserve le document comme Internet-Draft et affiche l’état RFC Ed Queue. Le RFC Editor indique blocked: Reference Not Received. En parallèle, l’examen IANA est IANA OK - Actions Needed et l’action IANA est In Progress.

Ces mentions ne sont pas de simples détails administratifs. Elles décrivent des surfaces de contrôle différentes. L’IESG décide de l’approbation du document dans le processus IETF ; le RFC Editor conduit la production du texte définitif ; IANA effectue les allocations et mises à jour de registres prévues par la spécification. Un résultat positif dans l’une de ces chaînes ne remplace pas automatiquement les autres.

La distinction est particulièrement importante ici parce que le blocage du RFC Editor correspond directement à une dépendance normative qui n’a pas encore atteint le même stade de maturité. Le compagnon CMS a été approuvé avant que le document dont il dépend pour une partie essentielle de son contenu algorithmique et X.509 n’ait achevé son propre passage devant l’IESG.

Une chaîne de dépendance visible dans les documents eux-mêmes

draft-ietf-lamps-cms-composite-kem-03 n’est pas une spécification autonome de Composite ML-KEM. Il adapte au contexte CMS les mécanismes définis dans le document compagnon draft-ietf-lamps-pq-composite-kem.

Cette séparation est structurante. La dépendance définit les constructions Composite ML-KEM et leurs combinaisons, ainsi que les conventions associées aux clés publiques et aux identifiants utilisés dans X.509. Le document CMS s’appuie sur ce socle afin de préciser comment ces mécanismes entrent dans KEMRecipientInfo, comment la clé d’un destinataire est obtenue à partir d’un certificat et comment les capacités sont annoncées dans SMIMECapabilities.

Le renvoi est explicite pour les opérations cryptographiques. Le projet CMS ne réinvente pas KeyGen, l’encapsulation ou la décapsulation ; il renvoie aux primitives définies par sa dépendance. La dépendance est également la source des identifiants Composite ML-KEM et des règles permettant de transporter les clés correspondantes dans des certificats X.509.

Le texte CMS ajoute ensuite la couche applicative : choix et emploi de ces identifiants dans CMS, construction de KEMRecipientInfo, traitement des certificats du destinataire et expression des capacités S/MIME.

Cette architecture documentaire crée une chaîne simple à résumer, mais difficile à gouverner avec un indicateur unique :

algorithme et représentation de clé → certificat X.509 → identifiants → CMS/KEMRecipientInfo → capacités annoncées → implémentation concrète → pair distant → production.

Si l’un de ces maillons reste mobile, l’opérateur doit savoir précisément quelle version a servi à l’intégration et aux tests.

La dépendance normative n’a pas encore terminé son propre contrôle IESG

Le projet CMS -03 cite précisément draft-ietf-lamps-pq-composite-kem-21 comme référence normative. Cette précision de version est importante : elle permet de comprendre exactement quel texte était supposé fournir le comportement normatif au moment de l’approbation du compagnon CMS.

Or le Datatracker de draft-ietf-lamps-pq-composite-kem affiche toujours IESG Evaluation::Revised I-D Needed. Deux positions DISCUSS restent enregistrées, et l’état indique qu’une nouvelle révision est nécessaire. Le document affiche également IANA OK - Actions Needed.

Cela ne signifie pas que le travail est bloqué sans perspective. Cela signifie simplement que la dépendance n’a pas encore atteint le même jalon que son compagnon CMS. Les positions DISCUSS doivent être traitées dans le processus IESG, une révision peut être nécessaire et les actions IANA doivent encore être achevées.

Il serait donc erroné de déduire de l’approbation du document CMS que la dépendance a elle aussi été approuvée ou que les deux DISCUSS sont déjà résolus.

Cette situation illustre un phénomène normal des familles de spécifications : un document applicatif peut être suffisamment mûr pour être approuvé alors qu’une référence normative étroitement liée poursuit encore son propre cycle. Le problème opérationnel n’est pas l’existence de ce décalage. Il apparaît lorsqu’une organisation réduit plusieurs états indépendants à une seule case « standardisé ».

Les espaces réservés montrent que la production reste dépendante

Le lien entre les deux documents n’est pas seulement conceptuel. Il apparaît dans leur mécanique de publication.

La révision CMS conserve des espaces réservés destinés au RFC Editor et dépend d’une attribution de module provenant de l’autre document. Le document demande notamment des traitements IANA associés à son module CMS, tandis que certaines valeurs ne peuvent être figées qu’une fois connues les allocations finales liées au document Composite ML-KEM.

La dépendance -21 contient elle aussi les éléments nécessaires à son module ASN.1 et aux identifiants associés. Le traitement complet exige donc que les valeurs provisoires soient remplacées de manière cohérente dans les textes définitifs.

C’est précisément le type de dépendance que traduit un état RFC Editor comme blocked: Reference Not Received. Le compagnon approuvé peut être présent dans la file de production sans pouvoir être finalisé tant que le document normatif dont il dépend n’est pas suffisamment avancé.

Pour un opérateur, cette situation devrait être représentée explicitement dans le suivi interne. « Approuvé » et « publiable sans dépendance ouverte » ne sont pas la même propriété.

IANA : des identifiants visibles sans chaîne entièrement terminée

Le registre IANA SMI affiche déjà les identifiants Composite ML-KEM 55 à 65. Cette présence est utile : elle donne une réalité administrative aux OID utilisés pour plusieurs combinaisons Composite ML-KEM.

Mais le registre illustre lui-même pourquoi l’existence d’un numéro n’est pas une preuve de clôture de toute la chaîne. Les entrées affichent encore une référence à une ancienne révision de la dépendance, alors que le projet normatif considéré par l’IESG est désormais la révision -21.

Dans le même temps, les traitements nécessaires aux modules et à la publication des documents ne sont pas tous terminés. Le document CMS affiche toujours une action IANA In Progress, et sa dépendance reste elle aussi dans un état indiquant que des actions sont requises.

Cette coexistence est importante à comprendre. Une allocation peut exister dans un registre avant que l’ensemble documentaire auquel elle appartient ait achevé son passage par l’IESG, IANA et le RFC Editor.

Un OID visible ne prouve donc pas que le RFC final est publié. Il ne prouve pas non plus qu’un fournisseur l’implémente, qu’un certificat contenant la clé correspondante sera accepté ou qu’un pair distant prendra en charge la même combinaison.

De la norme au service : plusieurs portes de contrôle

La chaîne opérationnelle complète comporte davantage d’étapes que la chaîne éditoriale :

approbation IESG → clôture des références normatives → actions IANA → production RFC → version logicielle disponible → activation d’une combinaison → certificat compatible → comportement CMS correct → interopérabilité entre les deux extrémités → autorisation de production.

Chaque transition peut échouer indépendamment.

Un fournisseur peut livrer les primitives cryptographiques sans exposer encore les bons mécanismes CMS. Une pile peut reconnaître un OID sans accepter les certificats nécessaires. Deux implémentations peuvent chacune réussir des vecteurs de test tout en divergeant sur la construction réelle d’un KEMRecipientInfo. Un produit peut annoncer une capacité que son interlocuteur ne prend pas en charge.

La difficulté n’est donc pas seulement cryptographique. Elle relève aussi de la gestion de versions, de certificats, de dépendances normatives, de négociation de capacités et de configuration bilatérale.

C’est pourquoi « le code existe » ou « l’algorithme est dans IANA » ne constitue pas un critère suffisant pour une décision d’exploitation.

Ce que les travaux d’interopérabilité prouvent réellement

L’annonce d’approbation mentionne une quantité importante de code ainsi que des travaux d’interopérabilité menés pendant des hackathons. C’est une preuve utile de maturité : le travail n’est pas purement théorique, des implémentations ont été produites et des échanges ont été testés.

Cette preuve doit toutefois rester bornée.

Elle ne démontre pas que toutes les implémentations possibles ont été testées. Elle ne démontre pas non plus que chaque combinaison Composite ML-KEM définie dans les documents fonctionne avec toutes les bibliothèques, toutes les chaînes de certificats, toutes les configurations CMS et toutes les versions logicielles susceptibles d’être rencontrées en production.

Un hackathon peut établir qu’une configuration donnée a interopéré à un moment donné. Ce résultat est précieux, mais son domaine de validité doit être conservé : versions testées, combinaison utilisée, certificats employés, paramètres CMS et conditions de l’échange.

La même discipline s’applique aux vecteurs de test. Un vecteur réussi prouve qu’une implémentation produit ou accepte le résultat attendu pour ce cas. Il ne prouve pas à lui seul que deux produits indépendants sauront s’échanger des messages de production, avec des certificats réels, dans les deux directions et après des mises à niveau.

Enfin, le consensus du groupe de travail sur les combinaisons à retenir est une preuve du résultat du processus de normalisation. Il ne constitue pas une preuve d’une demande universelle de la part des utilisateurs ou des opérateurs.

Le mécanisme d’impact : quand les états sont confondus

Le principal risque de gouvernance apparaît lorsqu’une organisation transforme une suite d’états distincts en un booléen unique, par exemple « PQC prêt ».

Supposons qu’une équipe commence ses essais sur la révision -21 de la dépendance, avec -03 du document CMS. Si une nouvelle révision de la dépendance modifie un détail normatif avant son approbation, les résultats précédents ne deviennent pas automatiquement inutiles, mais ils doivent être réévalués par rapport au texte finalement approuvé.

Même problème avec les allocations : une implémentation construite autour d’espaces réservés ou de valeurs provisoires doit être rapprochée des valeurs finales utilisées dans les RFC et les registres IANA.

Le problème devient plus subtil au niveau logiciel. Deux fournisseurs peuvent indiquer « Composite ML-KEM supporté » tout en couvrant des combinaisons différentes. Ils peuvent également diverger sur les versions de certificat prises en charge, la construction de KEMRecipientInfo ou les capacités exposées par SMIMECapabilities.

Dans ces conditions, l’état d’un seul produit ne suffit jamais à établir la capacité du service. La propriété qui compte est bilatérale : deux extrémités données, dans des versions données, doivent réussir l’échange attendu avec les mêmes hypothèses cryptographiques et de certificat.

Un reçu de dépendance plutôt qu’un simple indicateur d’activation

Une organisation qui souhaite déployer ces mécanismes a intérêt à créer un reçu de dépendance vérifiable pour chaque qualification significative.

Ce reçu devrait commencer par les artefacts normatifs : nom des deux documents, révisions exactes et empreintes des fichiers effectivement utilisés. Il devrait conserver les états observés du Datatracker, du RFC Editor et d’IANA avec leur date, ainsi que la référence normative reliant le compagnon CMS à la dépendance.

Il devrait également enregistrer les espaces réservés encore présents dans les textes et, plus tard, leur résolution. Lorsque les RFC seront publiés, les numéros RFC et allocations finales pourront être ajoutés sans effacer la provenance des essais conduits auparavant sur les Internet-Drafts.

Le reçu doit ensuite décrire la provenance algorithmique et des OID : quelle combinaison Composite ML-KEM est testée, quels identifiants sont utilisés, et à quelle version de spécification ils correspondent.

La couche CMS doit apparaître explicitement : support de KEMRecipientInfo, règles de certificat utilisées, SMIMECapabilities annoncées et comprises, paramètres de KDF et d’enveloppement applicables.

Enfin, il faut enregistrer les deux extrémités de l’échange. Nom et version des implémentations, configuration de chaque côté, certificats, vecteurs employés, résultats d’interopérabilité et périmètre exact de la réussite.

Ce reçu transforme une affirmation générale — « nous supportons Composite ML-KEM dans CMS » — en une preuve reproductible : « ces deux versions, avec cette combinaison, ces certificats et ces paramètres, ont réussi ce scénario ».

La préparation à la production est une décision supplémentaire

Même un reçu d’interopérabilité complet ne signifie pas automatiquement qu’un déploiement doit être activé.

La production ajoute des règles qui ne relèvent pas de la seule normalisation : quels correspondants sont autorisés, quelles combinaisons sont acceptées, quel comportement adopter si le pair ne prend pas en charge le mécanisme, comment traiter un certificat incompatible, et quelles alertes doivent être remontées.

Le repli doit notamment être explicite. Une implémentation ne devrait pas choisir silencieusement une méthode différente simplement parce que la combinaison attendue a échoué. Une organisation doit déterminer à l’avance si le repli est permis, vers quoi il peut s’effectuer et dans quelles circonstances il devient une erreur plutôt qu’une solution de continuité.

Le retour arrière doit lui aussi être préparé. Si une version logicielle déployée casse l’interopérabilité avec un partenaire critique, il faut savoir quelle version précédente peut être réactivée, avec quelles conséquences sur les certificats et sur les messages déjà produits.

Enfin, la sortie doit être considérée dès l’entrée. Une combinaison temporairement autorisée peut devenir difficile à retirer si elle se retrouve inscrite dans des certificats à longue durée de vie, des politiques de messagerie ou des archives. Plus un choix produit un état durable, plus la preuve exigée avant activation doit être forte.

Limites de preuve et incertitudes

Plusieurs limites doivent rester visibles.

Premièrement, draft-ietf-lamps-cms-composite-kem-03 a été approuvé par l’IESG, mais il n’est pas encore un RFC. Son état dans la file du RFC Editor et son blocage sur une référence non reçue le montrent directement.

Deuxièmement, draft-ietf-lamps-pq-composite-kem-21 n’a pas encore achevé son propre examen IESG. L’état Revised I-D Needed et les deux positions DISCUSS ne doivent pas être interprétés comme déjà résolus.

Troisièmement, les actions IANA ne sont pas terminées simplement parce que certains identifiants Composite ML-KEM apparaissent déjà dans le registre SMI. Les modules et traitements nécessaires aux documents restent une partie de la chaîne de publication.

Quatrièmement, l’existence de code et les travaux d’interopérabilité mentionnés par l’annonce IETF constituent une preuve bornée de mise en œuvre. Ils ne valident pas toutes les combinaisons, toutes les chaînes de certificats, tous les fournisseurs et tous les environnements de production.

Cinquièmement, le consensus obtenu au sein du groupe de travail prouve un résultat du processus IETF, non une demande universelle des utilisateurs.

Enfin, les états observés sont susceptibles d’évoluer rapidement : nouvelle révision de la dépendance, résolution des DISCUSS, clôture IANA, levée du blocage RFC Editor, puis publication. Cette mobilité renforce précisément la nécessité de dater et versionner les preuves opérationnelles.

Sources