Resumen

  • El objeto CMS nombra algoritmos en varios lugares. SignerInfo.digestAlgorithm debe coincidir con el prehash fijado por el OID compuesto, signatureAlgorithm debe usar ese OID y sus parámetros deben estar ausentes.
  • Las dos firmas válidas no completan la verificación: el receptor debe reconstruir los bytes DER exactos, recalcular el resumen del contenido, comparar la protección de algoritmos y aplicar por separado la política del certificado y del firmante.

El sistema celebró dos verificaciones correctas. La parte ML-DSA pasó; la parte tradicional también. Después, un auditor observó que el sobre CMS decía SHA-256 mientras el OID de la firma compuesta exigía otro prehash.

La aritmética había contestado una pregunta. El objeto había formulado dos preguntas incompatibles.

La revisión 05 de Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in Cryptographic Message Syntax (CMS) define cómo evitar esa ambigüedad. Es un Internet-Draft activo del grupo LAMPS, en el flujo IETF, con estatus previsto Proposed Standard. La revisión está fechada el 22 de mayo de 2026 y vence el 23 de noviembre. Datatracker registró un cambio de proceso el 1 de octubre y ahora la sitúa en la cola del RFC Editor, a la espera de un segundo editor. Todavía no es un RFC, ni prueba soporte, despliegue, emisión de certificados o migración completada.

El texto acompaña a la especificación de la primitiva Composite ML-DSA. Esa primitiva combina ML-DSA con RSA, ECDSA, Ed25519 o Ed448 y solo devuelve éxito si todas las firmas componentes son válidas. El documento CMS determina qué bytes y declaraciones exteriores llegan a esa operación.

Una interfaz única no elimina el sobre

La revisión reproduce 18 OID compuestos. El mismo AlgorithmIdentifier identifica la clave pública y la firma, y el campo de parámetros debe estar ausente. Así, las aplicaciones no tienen que inventar cómo empaquetar y combinar dos firmas independientes.

Sin embargo, CMS conserva otras autoridades. SignedData.digestAlgorithms contiene una colección de resúmenes. Cada SignerInfo incluye un resumen y un algoritmo de firma. Los atributos firmados pueden incluir CMSAlgorithmProtection. El certificado identifica la clave.

Una biblioteca no debería resolver contradicciones escogiendo el campo que entiende primero. El recibo necesita el OID compuesto, el algoritmo de la clave, los identificadores del SignerInfo, la presencia de parámetros, los valores protegidos y ambos resultados. “Firma PQ válida” es una etiqueta demasiado pequeña para esa decisión.

El algoritmo compuesto fija el prehash

Este perfil usa Composite ML-DSA únicamente en modo prehash. Cada nombre compuesto fija SHA-256, SHA-512 o SHAKE256 como resumen exterior de CMS. El digestAlgorithm del firmante debe ser exactamente el correspondiente.

Los parámetros de SHA-256 y SHA-512 deben omitirse. SHAKE256 también lleva parámetros ausentes y salida de 64 bytes. Una componente ECDSA puede usar internamente SHA-384 dentro de un compuesto cuyo prehash CMS es SHA-512; esa elección interior no altera el mapeo exterior.

Por eso la telemetría debe indicar la capa. Un digest interno distinto puede ser correcto. Un digest exterior distinto es una incoherencia. Mezclarlos en una lista sin contexto genera falsos positivos o esconde un fallo real.

El conjunto SignedData.digestAlgorithms debería contener el resumen correspondiente para ayudar a la verificación en una sola pasada. Su ausencia puede impedirla. No sustituye la igualdad obligatoria del SignerInfo: uno es una pista del contenedor; el otro declara el algoritmo de este firmante.

signedAttrs cambia el objeto firmado

Sin atributos firmados, la firma cubre el valor del OCTET STRING eContent, sin los octetos de etiqueta y longitud. Con atributos, cubre la codificación DER completa de SignedAttrs, incluidos etiqueta y longitud. Para la entrada se usa un tag EXPLICIT SET OF, no el IMPLICIT [0] que aparece en el mensaje final.

Los atributos contienen como mínimo content-type y message-digest. El receptor debe recalcular el resumen del contenido. Verificar la firma sobre una reconstrucción distinta, o aceptar el digest declarado sin compararlo, deja incompleta la validación CMS aunque ambas componentes matemáticas pasen.

La evidencia debe empezar por el hash del objeto CMS recibido. Después: hash del contenido, hash DER exacto de atributos, digest recibido, digest recalculado y bytes entregados al verificador compuesto. Una representación ASN.1 normalizada no reemplaza los bytes originales.

La primitiva tiene una cadena de contexto, pero este perfil la fija vacía. La separación entre una aprobación, un paquete de software y otro tipo de contenido no puede atribuirse aquí a un contexto criptográfico no vacío. Debe venir de reglas explícitas y verificadas.

Firmar también la selección de algoritmos

RFC 6211 creó CMSAlgorithmProtection para incluir el resumen y el algoritmo de firma o MAC dentro de los atributos firmados. RFC 8933 reforzó la coherencia. La revisión 05 recomienda el atributo para evitar sustitución de algoritmo.

Un campo exterior no firmado puede cambiar sin modificar la entrada de la firma. Un identificador dentro de SignedAttrs forma parte del DER protegido. El verificador puede comparar esa declaración con el SignerInfo, el OID compuesto y la clave, en lugar de dejar que la biblioteca elija silenciosamente.

La mera presencia no basta. Deben verificarse estructura, ubicación, OID, parámetros y compatibilidad. Como el draft dice SHOULD, una ausencia permitida debe quedar visible para la política, no transformarse en un éxito indistinto.

El registro y el documento muestran tiempos diferentes

La revisión solicita un identificador de módulo ASN.1. Su texto congelado conserva un marcador pendiente de sustitución. La captura pública de IANA del 2 de octubre ya muestra el decimal 88 para id-mod-composite-mldsa-cms-2026, con referencia al Internet-Draft.

No son estados equivalentes ni contradictorios: existe una asignación pública, el fuente conserva un marcador editorial, el documento está en la cola del RFC Editor y aún no hay número RFC. La asignación demuestra una fila del registro en esa fecha; no demuestra publicación o despliegue.

Dos componentes no autorizan la consecuencia

La primitiva exige que todas las componentes pasen y prohíbe reutilizar sus claves fuera del compuesto. Eso fortalece la respuesta criptográfica.

No confirma por sí solo la cadena, revocación, vigencia, key usage, autoridad del firmante, significado del documento o resultado. Una aprobación firmada no demuestra que el pago, la instalación o el cambio ocurrieron.

Los recibos deben permanecer separados: parseo y codificación; acuerdo de algoritmos; digest; resultados componentes; camino y estado del certificado; identidad y permiso; decisión local; entrega; persistencia; efecto externo.