Résumé

  • La RFC 9882 définit ML-DSA-44, ML-DSA-65 et ML-DSA-87 en mode pur pour CMS SignedData, mais pas HashML-DSA.
  • Deux voies existent : la valeur d’eContent sans attributs signés, ou l’encodage DER complet de SignedAttrs lorsque ces attributs sont présents.

Les OID complets sont 2.16.840.1.101.3.4.3.17, 2.16.840.1.101.3.4.3.18 et 2.16.840.1.101.3.4.3.19. Les paramètres de l’AlgorithmIdentifier ML-DSA DOIVENT être omis. Le contexte ML-DSA est vide.

Avec des attributs signés, le condensat doit offrir les lambda bits de sécurité du jeu ML-DSA contre les attaques de seconde préimage et de collision, avec une sortie d’au moins 2*lambda bits. La force est plafonnée par le plus faible niveau. Le Tableau 1 est exhaustif : 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 est obligatoire et SHAKE256 recommandé ; les deux identifiants omettent leurs paramètres.

Fixture à deux voies. La voie A s’applique en l’absence de signedAttrs. Elle signe seulement les octets de valeur de l’OCTET STRING eContent : ni tag ni longueur ne sont inclus. Pour l’interopérabilité, le signataire code SHA-512 dans digestAlgorithm, bien que ce champ n’ait aucune signification cryptographique sur cette voie ; le vérificateur en ignore le contenu. La voie A n’a ni content-type, ni message-digest, ni exigence de recalcul du message-digest ou du condensat du contenu. La voie B s’applique lorsque signedAttrs existe. Elle signe l’encodage DER complet de SignedAttrs, tag et longueur compris, avec le tag explicite SET OF, jamais le [0] implicite final. Elle contient au moins content-type et message-digest; seule cette voie exige que le destinataire recalcule le condensat du contenu et le compare à message-digest.

CMSAlgorithmProtection devrait être inclus dans les attributs signés afin de résister à la substitution d’algorithme. Il s’agit d’une recommandation normative, non d’une affirmation de déploiement. Un contenu volumineux peut rester hors de la frontière de signature HSM. Le calcul externe du représentant mu en mode pur est permis et détaillé dans l’appendice D de la RFC 9881 et la section 6.2 de FIPS 204. Les contrôles d’interface HSM et les propositions de mise en service relèvent de l’analyse de Theo March. Les signatures hedged et déterministes utilisent le même vérificateur ; la signature déterministe ne devrait pas être employée en cas de risque de canal auxiliaire ou de faute.

Lecture opérationnelle

Les règles normatives relèvent des RFC 9882, 5652, 6211 et 9881, ainsi que de FIPS 204. L’analyse de Theo March propose de capturer la voie, les longueurs et empreintes d’octets, l’OID, l’absence de paramètres, le tag, les attributs, l’identifiant de condensat, la comparaison du contenu sur la voie B, la frontière HSM et le résultat. Activation progressive, vérification en observation et retour arrière testé sont des recommandations, non des obligations RFC ni des preuves d’adoption. La RFC 9881 traite de PKIX, et la RFC 9879 d’un autre sujet.

Sources