Resumen

  • RFC 9881 especifica las variantes puras ML-DSA-44, ML-DSA-65 y ML-DSA-87 para certificados y CRL de PKIX.
  • Los OID completos son 2.16.840.1.101.3.4.3.17 para ML-DSA-44, 2.16.840.1.101.3.4.3.18 para ML-DSA-65 y 2.16.840.1.101.3.4.3.19 para ML-DSA-87. Sus niveles de seguridad son 2, 3 y 5, respectivamente.
  • El parámetro de AlgorithmIdentifier DEBE estar ausente, no codificado como NULL. signatureValue contiene la firma ML-DSA sin envolver sobre la estructura codificada en DER, con contexto vacío.

RFC 9881 convierte la identidad algorítmica en una regla exacta de codificación. El OID va en AlgorithmIdentifier y la firma cruda en signatureValue. La verificación debe realizarse sobre la estructura firmada codificada en DER, no sobre una reconstrucción equivalente pero distinta. En PKIX, el contexto opcional permanece vacío.

SubjectPublicKeyInfo transporta directamente los bytes de la clave pública ML-DSA, sin una envoltura ASN.1 adicional. Las claves miden 1.312 octetos para ML-DSA-44, 1.952 para ML-DSA-65 y 2.592 para ML-DSA-87. Si existe keyUsage, debe incluir al menos un bit de firma; los bits de cifrado y acuerdo de claves NO DEBEN usarse con claves ML-DSA. Esta es una distinción normativa.

OneAsymmetricKey puede llevar una semilla, una clave expandida o ambas representaciones. Se recomienda la forma que contiene solo la semilla para ahorrar almacenamiento. El analizador debe elegir mediante la etiqueta ASN.1, nunca mediante una heurística de longitud. Cuando aparecen ambas y la comprobación de consistencia falla, el receptor DEBE rechazar la clave como malformada.

El límite de RFC 9881 es ML-DSA puro. Los OID de HashML-DSA NO DEBEN aparecer en los protocolos PKIX cubiertos. Tampoco debe confundirse con Dilithium de preestandarización: ML-DSA y Dilithium no son compatibles. Una implementación que reconoce el nombre no puede aceptar automáticamente el formato del otro.

Fuentes