Кратко

  • RFC 9881 задаёт применение чистых вариантов ML-DSA-44, ML-DSA-65 и ML-DSA-87 в сертификатах и CRL PKIX.
  • Полные OID: 2.16.840.1.101.3.4.3.17 для ML-DSA-44, 2.16.840.1.101.3.4.3.18 для ML-DSA-65 и 2.16.840.1.101.3.4.3.19 для ML-DSA-87. Им соответствуют уровни безопасности 2, 3 и 5.
  • Компонент parameters в AlgorithmIdentifier ДОЛЖЕН отсутствовать, а не кодироваться как NULL. signatureValue содержит необёрнутую подпись над структурой в DER; контекст остаётся пустым.

В профиле PKIX идентичность алгоритма — это точная последовательность байтов. OID помещается в AlgorithmIdentifier, а необёрнутая подпись ML-DSA — в signatureValue. Проверять нужно DER-представление подписанной структуры, а не результат повторной сериализации. Для этого применения необязательный контекст пуст.

SubjectPublicKeyInfo содержит исходную строку байтов открытого ключа ML-DSA без дополнительной ASN.1-обёртки. Размеры составляют 1312 октетов для ML-DSA-44, 1952 для ML-DSA-65 и 2592 для ML-DSA-87. Если присутствует keyUsage, должен быть установлен хотя бы один бит подписи; биты шифрования и согласования ключа для ML-DSA устанавливать НЕЛЬЗЯ.

OneAsymmetricKey может содержать seed, expandedKey либо оба представления. Для экономии хранилища рекомендуется вариант только с seed. Разбор должен опираться на ASN.1-тег, а не на эвристику длины. Если присутствуют оба значения и проверка согласованности обнаруживает расхождение, получатель ДОЛЖЕН отклонить закрытый ключ как некорректный.

RFC 9881 выбирает чистый ML-DSA. OID HashML-DSA НЕЛЬЗЯ применять в охватываемых протоколах PKIX. Существует и граница с предшествующим стандартизации Dilithium: ML-DSA и Dilithium несовместимы. Узнавание имени не даёт оснований принимать чужой формат.

Источники