Resumen

  • El IESG aprobó el 18 de septiembre draft-ietf-lamps-cms-composite-kem-03 como Proposed Standard, pero el documento sigue siendo un Internet-Draft en producción editorial: Datatracker lo sitúa en RFC Ed Queue, el RFC Editor espera una referencia y IANA aún tiene trabajo pendiente.
  • El documento CMS no define por sí solo Composite ML-KEM. Delega en draft-ietf-lamps-pq-composite-kem-21 las operaciones fundamentales, el transporte de claves públicas en X.509 y los identificadores de los algoritmos; CMS añade cómo insertar esa capacidad en KEMRecipientInfo, certificados y SMIMECapabilities.
  • Para un operador, “aprobado”, “registrado”, “implementado”, “interoperable” y “activado en producción” deben tratarse como estados independientes. El control útil es un recibo verificable que vincule versiones y hashes exactos, referencias normativas, asignaciones IANA, software de ambos extremos, vectores de prueba, alcance real de interoperabilidad y reglas explícitas de despliegue, alternativa y reversión.

Una aprobación real que todavía no es publicación

El acontecimiento del 18 de septiembre es inequívoco. El anuncio del IESG dice que draft-ietf-lamps-cms-composite-kem-03, “Composite ML-KEM for use in Cryptographic Message Syntax (CMS)”, fue aprobado como Proposed Standard. El propio anuncio lo presenta como documento del grupo LAMPS y como acompañante de draft-ietf-lamps-pq-composite-kem-21.

Pero la aprobación del IESG es un punto de control, no el final del proceso. El historial muestra que ese mismo 18 de septiembre la revisión -03 pasó a RFC Ed Queue; el RFC Editor recibió el anuncio y, a continuación, el estado quedó bloqueado por Reference Not Received. También ese día la acción de IANA pasó a In Progress. La página vigente de Datatracker conserva esas mismas señales: RFC Ed Queue, revisión de IANA IANA OK - Actions Needed, acción IANA In Progress y RFC Editor blocked: Reference Not Received.

Esa distinción es operativamente más importante que la etiqueta “aprobado”. Un sistema que automatice decisiones de adquisición, integración o activación a partir de un único campo del Datatracker puede confundir una autorización de avance con una especificación editorialmente cerrada. Aquí la propia infraestructura de publicación expone lo contrario: el documento ha superado una puerta mientras otras siguen abiertas.

IANA también registra el borrador CMS entre los documentos que procesa en 2026 y lo muestra como In Progress; la explicación oficial de ese estado dice que las acciones para el documento están siendo procesadas.

La dependencia que contiene el significado criptográfico

La razón del bloqueo no es puramente administrativa. El documento CMS está diseñado como una capa de uso, no como la definición autosuficiente de Composite ML-KEM. Su introducción dice que draft-ietf-lamps-pq-composite-kem define la colección de algoritmos y que el texto CMS proporciona las convenciones para utilizarlos mediante la estructura KEMRecipientInfo de RFC 9629.

La división de responsabilidades es concreta. Para KeyGen(), encapsulación y decapsulación, el documento CMS remite a las secciones correspondientes del borrador Composite ML-KEM. Incluso advierte de una diferencia de orden en los valores devueltos por Encapsulate() y Encaps(), una señal de que implementar ambos documentos exige mapear interfaces con precisión y no sólo reconocer el nombre de un algoritmo.

La misma dependencia aparece en los certificados. El documento CMS exige una clave pública estática del destinatario y dice que el originador la obtiene de su certificado, pero deja en draft-ietf-lamps-pq-composite-kem las convenciones para transportar esas claves públicas Composite ML-KEM en X.509. Después, la capa CMS especifica cómo anunciar compatibilidad mediante SMIMECapabilities: una implementación puede anunciar uno o más identificadores Composite ML-KEM, y el capabilityID utiliza el OID correspondiente sin parámetros.

El RFC 9629 aporta el armazón previo. KEMRecipientInfo contiene, entre otros elementos, la identificación del destinatario, el algoritmo KEM, el ciphertext KEM, la KDF, la longitud de la KEK, el algoritmo de envoltura y la clave cifrada. También define el flujo por el que encapsulación y decapsulación producen el secreto compartido que alimenta la derivación de la KEK. El nuevo documento CMS no reemplaza ese mecanismo: inserta Composite ML-KEM dentro de él.

Dos documentos, dos relojes

La asimetría aparece al mirar el documento del que depende CMS. A 21 de septiembre de 2026, draft-ietf-lamps-pq-composite-kem-21 sigue siendo un Internet-Draft activo. Datatracker lo sitúa en IESG Evaluation::Revised I-D Needed y registra dos posiciones DISCUSS, indicando que existen suficientes posiciones para aprobarlo una vez resueltas. Su revisión de IANA sigue en IANA OK - Actions Needed.

Por tanto, no existe una única “fase Composite ML-KEM”. Hay al menos dos cronologías independientes. El documento CMS ya tiene aprobación del IESG y ha entrado en la producción RFC. El documento que define el algoritmo compuesto, su uso en PKIX y sus identificadores todavía requiere una revisión del Internet-Draft y el cierre de cuestiones del ballot.

Eso permite que el documento complementario llegue a una cola editorial antes de que su referencia normativa esté disponible como referencia publicable. Reference Not Received es, en este contexto, una manifestación visible de una dependencia entre documentos y no una objeción criptográfica nueva contra el texto CMS.

La consecuencia para gestión tecnológica es clara: la fecha de aprobación de una capa superior no debe convertirse automáticamente en la fecha de disponibilidad de la capacidad que esa capa describe.

Los marcadores pendientes hacen visible la dependencia

La revisión -03 del documento CMS fija expresamente su referencia normativa en draft-ietf-lamps-pq-composite-kem-21. Eso da una base concreta para revisión, pero no convierte -21 en un artefacto final. El documento dependiente todavía puede producir una revisión posterior como parte de Revised I-D Needed.

Hay además un marcador editorial que une físicamente ambos procesos. La sección de consideraciones IANA de CMS solicita un identificador para su módulo ASN.1 y conserva una instrucción al RFC Editor para sustituir TBDCompositeMOD por el número asignado a id-mod-composite-mlkem-2025 en el documento Composite ML-KEM.

El borrador de la dependencia contiene a su vez id-mod-composite-mlkem-2025(TBDMOD) y solicita a IANA el registro correspondiente. En otras palabras, hay una dependencia no sólo semántica sino también de producción: un valor pendiente en el módulo CMS espera un valor final procedente de la especificación subyacente.

Para una organización que necesite demostrar exactamente qué material aprobó, probó o desplegó, el nombre del borrador no basta. El recibo debería fijar la revisión exacta y un hash del contenido utilizado. De otro modo, “probado contra draft-ietf-lamps-pq-composite-kem” puede terminar describiendo un artefacto distinto del que finalmente se publique.

IANA: un identificador visible no es el final de la cadena

El registro SMI de IANA ofrece un ejemplo especialmente útil de por qué la procedencia importa. En el registro de algoritmos PKIX ya aparecen los valores 55 a 65 para varias combinaciones Composite ML-KEM. Sin embargo, esas filas visibles hacen referencia a draft-ietf-lamps-pq-composite-kem-10, una revisión mucho más antigua que la actual -21.

El dato de registro es real. Lo que no demuestra por sí solo es que todo el paquete normativo haya terminado su recorrido, que la representación de certificados esté congelada, que el módulo CMS haya recibido su asignación definitiva o que una combinación concreta sea utilizable en un entorno de producción determinado.

Esta distinción evita dos errores opuestos. El primero sería ignorar los OID porque el RFC todavía no existe; los números ya son visibles y pueden formar parte de implementaciones o pruebas. El segundo sería interpretar su mera presencia como prueba de cierre normativo y operativo. Tampoco es correcto.

Lo que necesita un inventario serio es procedencia: qué registro contiene el valor, qué revisión figura como referencia, qué revisión utiliza el software, qué texto normativo describe ese OID y qué referencia final lo sustituye cuando se publiquen los RFC.

La superficie de control es una cadena, no un interruptor

La normalización suele representarse como una secuencia documental, pero la adopción real atraviesa varias superficies de control. El IESG controla la aprobación de cada documento. El RFC Editor controla la transformación editorial y la coordinación de referencias. IANA ejecuta asignaciones de registros. Los mantenedores de bibliotecas deciden qué algoritmos, OID y estructuras soporta cada versión. Las autoridades o plataformas de certificados determinan si una clave Composite ML-KEM puede emitirse y transportarse correctamente. Las aplicaciones CMS deciden si procesan KEMRecipientInfo y qué capacidades anuncian. Finalmente, los operadores deciden si permiten esa combinación en producción.

Ningún estado sustituye al siguiente.

Un OID asignado no instala código. Código instalado en un extremo no crea compatibilidad bilateral. Dos implementaciones que procesan un vector de prueba no prueban una ruta de certificados completa. Una ruta de certificados correcta no demuestra que ambos extremos anuncien y negocien las mismas capacidades. Y un intercambio exitoso en laboratorio no crea por sí solo una política operativa de producción.

Éste es el mecanismo económico del problema: una organización puede asumir costes de integración antes de que la dependencia documental, la disponibilidad del software y la compatibilidad bilateral converjan. La cuestión no es sólo si la criptografía funciona, sino cuándo los distintos propietarios de esas dependencias alcanzan un estado que la organización está dispuesta a aceptar.

Interoperabilidad: evidencia importante, pero acotada

El anuncio del IESG afirma que se ha escrito mucho código y que se dedicó un esfuerzo considerable en hackathons a comprobar la interoperabilidad entre diversas implementaciones. Es evidencia positiva de actividad de implementación y de pruebas interop; no es una afirmación de despliegue universal.

La misma cautela se aplica al consenso. El resumen del grupo de trabajo señala que hubo debate, que muchos participantes pidieron menos combinaciones y que finalmente existía interés en cada una de las combinaciones especificadas, con consenso del grupo. Eso demuestra un resultado de normalización dentro de LAMPS. No demuestra demanda universal ni que cada combinación vaya a ser ofrecida por todos los proveedores.

Por eso el nivel de prueba debe mantenerse separado. Un vector correcto valida una propiedad concreta. Una pareja de implementaciones interoperables valida esa pareja y esa configuración. Un hackathon puede ampliar la evidencia a más software y combinaciones. Ninguna de esas capas demuestra automáticamente compatibilidad entre todas las versiones, todas las combinaciones, todas las cadenas de certificados y todas las políticas de producción.

El recibo de dependencia que falta en muchas operaciones

Para convertir esta clase de transición en una decisión auditable, el objeto útil no es una captura de pantalla que diga “Approved”, sino un recibo de dependencia.

Ese recibo debería unir las versiones exactas de ambos documentos y sus hashes; el estado de cada uno y la hora en que fue observado; la referencia normativa concreta que los enlaza; cualquier marcador todavía pendiente del RFC Editor; la procedencia de algoritmos, OID y módulos ASN.1; el cierre de las posiciones DISCUSS y de las revisiones relevantes; los números RFC y asignaciones IANA finales cuando existan; y las combinaciones que una organización haya decidido soportar.

Después debe extenderse al plano de implementación: tratamiento concreto de KEMRecipientInfo, representación aceptada en certificados, declaraciones de SMIMECapabilities, versión de biblioteca o producto en ambos extremos y conjunto exacto de vectores de prueba ejecutados.

Por último necesita un alcance de interoperabilidad. “Interoperable” debe significar quién habló con quién, usando qué versiones, qué combinación Composite ML-KEM, qué formato de certificado, qué contenido CMS y bajo qué configuración. Sólo después debería añadirse la decisión de producción: dónde se habilita, cuál es la alternativa cuando el receptor no puede procesarla, qué señal dispara la reversión y cómo se abandona una combinación o una implementación si cambia el estándar o aparece un defecto.

Ese recibo convierte una cadena de estados parcialmente independientes en una evidencia que puede seguirse a través del tiempo.

Límites de evidencia e incertidumbre

La fotografía actual no permite decir que draft-ietf-lamps-cms-composite-kem-03 sea ya un RFC. El propio Datatracker sigue describiéndolo como Internet-Draft y lo sitúa en la cola del RFC Editor. Tampoco permite afirmar que draft-ietf-lamps-pq-composite-kem-21 esté aprobado: su estado sigue siendo Revised I-D Needed y mantiene dos DISCUSS.

No hay base para afirmar que IANA haya terminado. En el documento CMS, la acción continúa In Progress; en la dependencia, la revisión todavía dice IANA OK - Actions Needed.

Tampoco las fuentes citadas prueban que todas las combinaciones Composite ML-KEM estén desplegadas o sean aceptadas bilateralmente en sistemas productivos. La evidencia pública muestra trabajo de implementación e interoperabilidad y una arquitectura normativa bastante concreta. El salto desde esa evidencia hasta disponibilidad comercial o preparación operacional universal sería una inferencia no sustentada.

La incertidumbre importante está, por tanto, en la convergencia: qué cambiará en la próxima revisión de la dependencia, cuándo se resolverán sus DISCUSS, cuándo se fijarán referencias y números de módulo, y qué versiones de software acabarán implementando la forma final.

Fuentes