Resumen

  • Si no hay atributos firmados, ML-DSA firma directamente los octetos del contenido; digestAlgorithm debe indicar SHA-512 por compatibilidad, pero el verificador debe ignorar el valor.
  • Si hay atributos firmados, el resumen del contenido sí queda dentro de la materia protegida, debe recalcularse y puede limitar la resistencia de la construcción completa.
  • Una conclusión auditable separa la rama, los bytes exactos, el OID del conjunto de parámetros, la comparación del resumen, la protección de algoritmos, los límites de clave y μ, la autorización y el resultado.

Supongamos que un registro afirma que el algoritmo de resumen fue SHA-512, el de firma ML-DSA-65 y la validación resultó correcta. Nada de eso obliga a concluir que SHA-512 procesó el contenido para esa firma. Tampoco demuestra que la clave permaneciera dentro de un HSM ni que la persona identificada tuviera facultad para aprobar la acción posterior.

RFC 9882 apareció en octubre de 2025 como estándar propuesto del IETF. Establece la forma de utilizar en Cryptographic Message Syntax los conjuntos ML-DSA-44, ML-DSA-65 y ML-DSA-87 de FIPS 204. Cada uno tiene un OID de firma propio y los parámetros del AlgorithmIdentifier deben estar ausentes. La especificación cubre ML-DSA puro, no HashML-DSA en CMS. Aunque ML-DSA se conoció antes como Dilithium, ambos formatos no son compatibles.

La primera pregunta de cualquier revisión es si existe signedAttrs.

Cuando no existe, ML-DSA recibe los octetos que forman el valor del OCTET STRING encapContentInfo eContent; quedan fuera los octetos de etiqueta y longitud. Al tratarse de ML-DSA puro, se firma el mensaje directamente. En esta rama, SignerInfo.digestAlgorithm carece de significado para el cálculo de la firma.

La norma, sin embargo, no permite dejar el campo al arbitrio del emisor. Obliga a consignar SHA-512 para reducir problemas entre implementaciones. Al mismo tiempo obliga al receptor a ignorar su contenido. Por tanto, ese SHA-512 certifica el uso de una convención de interoperabilidad, no una etapa externa de resumen. El dato es correcto; convertirlo en explicación causal es el error.

Con atributos firmados, cambia aquello que recibe ML-DSA. Se firma la codificación DER completa del valor SignedAttrs, con etiqueta y longitud, y con la etiqueta EXPLICIT SET OF en lugar de la IMPLICIT [0] que aparece en el mensaje terminado. Deben figurar, como mínimo, el tipo de contenido y el resumen del mensaje. El receptor calcula de nuevo ese resumen sobre el contenido y lo compara con el atributo. Aquí el algoritmo de resumen sí importa y una elección insuficiente puede fijar el techo de seguridad. RFC 9882 exige soporte para SHA-512 y recomienda SHAKE256, cuyo identificador tampoco debe llevar parámetros.

Esta bifurcación impide que “firma válida” sea un informe suficiente. Sin saber qué rama se procesó no se sabe qué significaba digestAlgorithm, qué bytes quedaron bajo ML-DSA ni si se verificó la vinculación entre contenido y atributo. El veredicto matemático debe conservar sus premisas.

La identidad algorítmica se comprueba aparte. El OID ha de corresponder al conjunto de parámetros ML-DSA usado, y la presencia de parámetros prohibidos merece rechazo. CMSAlgorithmProtection, definido en RFC 6211, copia los identificadores relevantes dentro de un atributo firmado. RFC 9882 recomienda incluirlo para evitar sustituciones. Que exista y que sea coherente son hechos que deben registrarse, no consecuencias automáticas de una firma correcta.

La custodia tampoco queda resuelta. El robo de una clave privada ML-DSA permite falsificar. FIPS 204 utiliza por defecto una generación reforzada con aleatoriedad nueva y datos aleatorios precomputados en la clave, y admite asimismo un modo determinista. RFC 9882 aconseja no emplear este último cuando preocupan los canales laterales o los ataques por fallos. El objeto CMS no aporta por sí solo evidencia sobre esa elección.

Un HSM introduce otra interfaz, no una respuesta universal. Con atributos firmados puede recibir solamente el pequeño bloque DER, en vez del contenido completo. ML-DSA puro también admite que otro módulo criptográfico calcule el representante μ y se lo entregue al firmante. La frase “la firma salió del HSM” no prueba, entonces, que el HSM viera el documento original o derivara μ. Hay que acreditar el origen, la interfaz y la vinculación con los bytes retenidos.

El expediente defendible conserva el objeto CMS original, registra la presencia de atributos, reconstruye la entrada exacta, identifica el OID y rechaza parámetros indebidos. En la rama correspondiente recalcula y compara el resumen; después comprueba la protección de algoritmos y la firma. Solo entonces añade, cuando se conocen, el modo de aleatoriedad y la frontera de μ, y evalúa por separado la cadena de certificados, la identidad, la autorización y el efecto en la aplicación.

Fuentes