Résumé

  • La RFC 9881 définit l’emploi PKIX des variantes pures ML-DSA-44, ML-DSA-65 et ML-DSA-87 dans les certificats et les CRL.
  • Les OID complets sont 2.16.840.1.101.3.4.3.17 pour ML-DSA-44, 2.16.840.1.101.3.4.3.18 pour ML-DSA-65 et 2.16.840.1.101.3.4.3.19 pour ML-DSA-87. Ils correspondent aux niveaux de sécurité 2, 3 et 5.
  • Le champ parameters de AlgorithmIdentifier DOIT être absent, et non codé NULL. La signature brute porte sur la structure signée encodée en DER, avec un contexte vide.

Dans PKIX, l’identité algorithmique est une convention d’octets. L’OID figure dans AlgorithmIdentifier et la signature ML-DSA brute dans signatureValue. Le vérificateur doit valider la signature sur l’encodage DER de la structure signée, et non sur une nouvelle sérialisation qui lui ressemblerait. Pour cet usage PKIX, le contexte facultatif reste vide.

SubjectPublicKeyInfo contient directement la chaîne d’octets de la clé publique ML-DSA, sans enveloppe ASN.1 supplémentaire. Les tailles sont de 1 312 octets pour ML-DSA-44, 1 952 pour ML-DSA-65 et 2 592 pour ML-DSA-87. Si keyUsage est présent, au moins un bit lié à la signature doit être activé ; les bits de chiffrement et d’accord de clés DOIVENT être absents pour une clé ML-DSA. Ce sont des exigences normatives, non des conseils d’exploitation.

OneAsymmetricKey peut contenir une graine, une clé développée, ou les deux. La forme contenant seulement la graine est recommandée pour économiser l’espace. Le parseur doit choisir la représentation selon l’étiquette ASN.1, jamais selon la longueur supposée. Si les deux formes sont présentes et que le contrôle de cohérence échoue, le destinataire DOIT rejeter la clé comme malformée.

La RFC 9881 retient ML-DSA pur. Les OID HashML-DSA NE DOIVENT PAS être employés dans les protocoles PKIX couverts. La limite est également nette avec Dilithium antérieur à la normalisation : ML-DSA et Dilithium ne sont pas compatibles. Un nom reconnu ne justifie donc pas l’acceptation d’un autre format filaire.

Sources