Кратко

  • RFC 9882 задаёт чистые варианты ML-DSA-44, ML-DSA-65 и ML-DSA-87 для CMS SignedData, но не задаёт HashML-DSA.
  • Наличие signedAttrs разделяет путь значения eContent и путь полного DER SignedAttrs.

Полные OID: 2.16.840.1.101.3.4.3.17, 2.16.840.1.101.3.4.3.18 и 2.16.840.1.101.3.4.3.19. Параметры AlgorithmIdentifier ML-DSA должны отсутствовать; контекстная строка ML-DSA пуста.

При наличии подписанных атрибутов дайджест должен обеспечивать лямбда бит безопасности данного набора ML-DSA против атак на второе прообразование и коллизионных атак и выдавать не менее 2*лямбда бит. Общую стойкость ограничивает меньший уровень. Полная таблица 1: 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 обязательна, SHAKE256 рекомендуется; параметры обоих идентификаторов опускаются.

Двухпутевой байтовый fixture. Путь A используется без signedAttrs. Он подписывает только байты значения OCTET STRING eContent; байты тега и длины исключаются. Для совместимости подписывающая сторона кодирует SHA-512 в digestAlgorithm; на пути A поле не имеет криптографического смысла, а проверяющая сторона игнорирует его содержимое. Путь A не содержит content-type или message-digest и не требует пересчёта message-digest либо хэша содержимого. Путь B используется при наличии signedAttrs. Он подписывает полное DER-представление SignedAttrs вместе с тегом и длиной, используя явный тег SET OF, а не финальную неявную оболочку [0]. Он содержит как минимум content-type и message-digest; только путь B требует от получателя заново вычислить хэш содержимого и сравнить его с message-digest.

В подписанных атрибутах следует включать CMSAlgorithmProtection, чтобы противодействовать подмене алгоритма. Это нормативная рекомендация, а не заявление о внедрении. Большие данные могут оставаться вне границы подписи HSM. Внешнее вычисление представителя mu чистого режима разрешено и описано в RFC 9881 Appendix D и FIPS 204 Section 6.2. Управление интерфейсом HSM и последовательность внедрения — анализ Theo March. Hedged- и детерминированные подписи используют один алгоритм проверки; при угрозах побочных каналов или сбоев детерминированную подпись применять не следует.

Операционное толкование

Нормативные правила следуют из RFC 9882, RFC 5652, RFC 6211, RFC 9881 и FIPS 204. Анализ Theo March предлагает регистрировать путь, длины и отпечатки байтов, OID, отсутствие параметров, теги, атрибуты, идентификатор дайджеста, сравнение хэша на B, границу HSM и результат проверки. Поэтапное включение, теневые проверки и испытанный откат — рекомендации, а не требования RFC и не доказательства внедрения. RFC 9881 относится к PKIX, RFC 9879 имеет иной предмет.

Источники