Resumen

  • RFC 9882 define ML-DSA-44, ML-DSA-65 y ML-DSA-87 en modo puro para CMS SignedData, no HashML-DSA.
  • La ausencia o presencia de signedAttrs determina si se firma el valor de eContent o el DER completo de SignedAttrs.

Los OID completos son 2.16.840.1.101.3.4.3.17, 2.16.840.1.101.3.4.3.18 y 2.16.840.1.101.3.4.3.19; los parámetros de AlgorithmIdentifier ML-DSA deben omitirse. El contexto ML-DSA está vacío.

Con atributos firmados, el resumen debe proporcionar los lambda bits de seguridad del conjunto ML-DSA frente a ataques de segunda preimagen y colisión, y producir al menos 2*lambda bits. La fuerza queda limitada por el menor nivel. La Tabla 1 completa es: ML-DSA-44—SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256; ML-DSA-65—SHA-384, SHA-512, SHA3-384, SHA3-512, SHAKE256; ML-DSA-87—SHA-512, SHA3-512, SHAKE256. SHA-512 es obligatorio y SHAKE256 recomendado; ambos identificadores omiten parámetros.

Fixture de dos rutas. La ruta A se usa cuando no hay signedAttrs. Firma únicamente los octetos de valor del OCTET STRING eContent, excluyendo etiqueta y longitud. Para interoperabilidad, el firmante codifica SHA-512 en digestAlgorithm; ese campo no tiene significado criptográfico en esta ruta y el verificador ignora su contenido. La ruta A no tiene content-type, ni message-digest, ni exige recalcular el message-digest o el hash del contenido. La ruta B se usa cuando sí hay signedAttrs. Firma la codificación DER completa de SignedAttrs, con etiqueta y longitud y con la etiqueta explícita SET OF, nunca la [0] implícita final. Incluye al menos content-type y message-digest; solo la ruta B exige que el receptor recalcule el hash del contenido y lo compare con message-digest.

CMSAlgorithmProtection debería incluirse en los atributos firmados para resistir la sustitución de algoritmos. Es una recomendación normativa, no una afirmación sobre despliegues. El contenido grande puede permanecer fuera de la frontera de firma del HSM. El cálculo externo del representante mu en modo puro está permitido y se describe en el Apéndice D de RFC 9881 y la Sección 6.2 de FIPS 204. Los controles de interfaz HSM y la secuencia de despliegue son análisis de Theo March. Las firmas hedged y deterministas usan el mismo verificador; la firma determinista no debería usarse ante riesgos de canal lateral o fallos.

Lectura operativa

Las reglas normativas proceden de RFC 9882, RFC 5652, RFC 6211, RFC 9881 y FIPS 204. El análisis de Theo March propone registrar la ruta, longitudes y huellas de bytes, OID, parámetros ausentes, etiquetas, atributos, identificador de resumen, comparación del hash en B, frontera HSM y resultado. Activación gradual, verificación en sombra y reversión probada son recomendaciones, no requisitos RFC ni pruebas de adopción. RFC 9881 trata PKIX y RFC 9879 queda fuera del alcance.

Fuentes