Кратко

  • 10 сентября 2026 года IESG отклонила апелляцию, сняла задержку публикации и разослала уведомление об одобрении draft-ietf-tls-mldsa-05. Документ описывает применение подписей ML-DSA из FIPS 204 для аутентификации в TLS 1.3. Его предполагаемый статус — информационный RFC; на момент проверки он оставался Internet-Draft без номера RFC.
  • В реестре TLS SignatureScheme IANA находятся mldsa44, mldsa65 и mldsa87 со значениями 0x0904, 0x0905 и 0x0906. Все три имеют отметку N. По RFC 9847 она означает, что IETF не сделала заявления о пригодности либо консенсуса нет; это не отметка D, обозначающая нежелательность применения.
  • Одобрение публикации, выделение совместимых идентификаторов и рекомендация внедрения — разные действия. Решение по апелляции завершает процедурный спор о публикации, но не выбирает чистый или композитный ML-DSA за каждого оператора.
  • Внедряющая сторона должна оформить локальную квитанцию решения: поверхность TLS, вариант и набор параметров, круг узлов и сертификатов, датированные доказательства, границы отказа, владелец отката и дата следующего пересмотра.

Завершено решение о публикации

История Datatracker показывает две стадии. 8 июля IESG одобрила документ, но в тот же день задержала его из-за апелляции. 10 сентября апелляцию отклонили, удержание сняли и вернули документ в состояние отправленного уведомления. Официальное объявление называет его продуктом рабочей группы TLS, предназначенным для информационного статуса.

Разногласия из записи не исчезли. В сводке сопровождающего указано около 275 сообщений, а соотношение в пользу продвижения оценено примерно как четыре к одному. Участники предлагали не публиковать чистый ML-DSA, рекомендовать композитные схемы либо выпускать оба направления. Ответ IESG утверждает, что совет изучил материалы Working Group Last Call, увидел широкую поддержку и убедился: возражения были рассмотрены и обсуждены. Директор области безопасности Deb Cooley в решении не участвовала.

Этот вывод подтверждает rough consensus на публикацию при сохраняющихся возражениях. Он не превращает соотношение сообщений в голосование за эксплуатацию и не доказывает криптографическую ошибочность или безошибочность одной стороны. Процесс отвечает, мог ли документ двигаться дальше. Риск конкретной цепочки сертификатов, парка клиентов и режима отката остается за тем, кто ими управляет.

Между одобрением и готовым RFC остается производственный этап. Текущая карточка показывает Approved-announcement sent, но по-прежнему называет версию 05 активным Internet-Draft. Проверка IANA имеет состояние Version Changed - Review Needed, действие — In Progress. Номера RFC пока нет. Поэтому точная формулировка — «одобрено для публикации», а не «уже опубликовано как номерной RFC».

Три значения обеспечивают общий смысл

FIPS 204 стандартизирует постквантовый алгоритм цифровой подписи ML-DSA. Документ IETF выполняет более узкую задачу: соединяет три набора параметров с согласованием алгоритмов подписи в TLS 1.3. ML-DSA-44 соответствует mldsa44/0x0904, ML-DSA-65 — mldsa65/0x0905, ML-DSA-87 — mldsa87/0x0906.

RFC 9881 задает соответствующие AlgorithmIdentifier для X.509. TLS-документ связывает их со значениями SignatureScheme. Если значение используется в CertificateVerify, подпись и проверка выполняются по FIPS 204 с пустым ctx, а конечный сертификат должен содержать подходящий AlgorithmIdentifier. Варианты HashML-DSA с предварительным хешированием сюда не входят.

Такая определенность позволяет независимым реализациям сформировать и распознать одно сообщение. Она не доказывает, что удостоверяющий центр выдаст нужную цепочку, клиенты ее примут, выбранное оборудование безопасно обработает ключи или смешанный парк вернется назад после частичного включения. Совместимость формата — обязательная часть доказательств, но не весь эксплуатационный вывод.

Три строки уже видны в действующем реестре IANA с N. Ссылка в нем пока ведет на более раннюю версию черновика, а Datatracker показывает продолжающуюся работу IANA. Оба факта нужно сохранить: значения выделены и опубликованы; обновление ссылок и финальная редакционная цепочка еще не полностью закрыты.

N — не отказ

RFC 9847 определяет не двоичный, а трехсоставный столбец рекомендаций. Y означает консенсус IETF о том, что элемент рекомендован и пригоден для определенной цели с учетом ограничений применимости. D обозначает нежелательное применение и требует основания. N сообщает, что IETF не оценила или не заявила пригодность, консенсуса нет либо применение ограничено.

RFC прямо уточняет: N не обязательно означает дефект механизма. Следовательно, выделенный codepoint — не зеленый сигнал, но N — и не красный. Реестр дает реализации общий объект для испытаний, не подменяя отсутствующую общую рекомендацию.

Если номер трактовать как одобрение безопасности, техническое ведение реестра неожиданно становится органом допуска. Если N переводить как «запрещено», исчезает разница между отсутствием оценки и отрицательным решением. В обоих случаях общей инфраструктуре приписывают полномочия, которых она не заявляла.

Чистый и композитный варианты имеют разный статус

Одобренный документ описывает чистый ML-DSA. Отдельный активный индивидуальный Internet-Draft предлагает композитную подпись, сочетающую ML-DSA с традиционным алгоритмом в TLS 1.3. Datatracker указывает, что индивидуальный черновик не поддержан потоком IETF. Он подтверждает наличие проработанной альтернативы, но не равную институциональную рекомендацию.

Выбор зависит от модели угроз. Чистый профиль не требует успешной проверки второй подписи, зато сосредоточивает гарантии в ML-DSA и ее реализации. Композитный способен сохранить традиционный компонент при проблеме в новом алгоритме или коде, но увеличивает сертификаты, сообщения, вычисления и число точек несовместимости. Информационный статус не взвешивает эти издержки за конкретную службу.

Список реализаций из объявления тоже имеет ограниченный смысл. Код в OpenSSL, BoringSSL, rustls-post-quantum, s2n-tls, wolfSSL, Bouncy Castle или GnuTLS показывает реальную инженерную работу. Он не показывает включение по умолчанию, производственный трафик, общие цепочки, приемлемую задержку или испытанное выключение во всем парке.

Квитанция внедрения создается у оператора

Сначала нужно назвать точный объект, а не писать «готовность к постквантовой эпохе». Серверная и клиентская аутентификация, ограниченная частная служба и публичный эксперимент имеют разные границы. Набор параметров ML-DSA и чистый или композитный профиль должны быть явными.

Затем определяется популяция: издатели, профили сертификатов, конечные узлы, клиенты, библиотеки и аппаратные границы ключей. Правило согласования должно заранее отвечать, что произойдет, если партнер не объявит новое значение. Соединение отвергается, показывается другая цепочка, трафик перенаправляется или разрешен откат к прежнему алгоритму? Невидимый fallback может сохранить доступность и одновременно убрать искомую гарантию.

Доказательствам нужны дата и разнообразие. Проверка совместимости должна соединять разные семейства реализаций, а не только две сборки одной библиотеки. Размер рукопожатия, CPU и задержка измеряются при реалистичной параллельности. Генерация ключа, подпись, проверка, случайный или детерминированный режим и утечки реализации рассматриваются в фактической операционной границе. Выдачу и проверку полной цепочки нельзя заменять изолированной подписью.

Наконец, квитанция называет того, кто расширяет и кто выключает охват, метрики для отката, способ вывода распределенных ключей и сертификатов, срок действия доказательств и дату нового решения. Она не меняет IANA. Она делает подотчетным тот выбор, который IETF оставила локальным.

Границы доказательств

Источники не подтверждают включение по умолчанию или общее производственное использование. Они не устанавливают универсальное превосходство чистого либо композитного профиля. Ответ на апелляцию — процедурная оценка, не криптографическое доказательство. Стандарт NIST не оценивает конкретное внедрение TLS. Видимые строки реестра не доказывают завершение всей работы IANA и RFC Editor.

Проверяемый итог уже этого: IETF разрешила опубликовать совместимое описание трех наборов ML-DSA для TLS 1.3, а реестр сохранил рекомендацию N. Следующее решение и его доказательства принадлежат внедряющей стороне.

Источники

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Уведомление об одобрении Use of ML-DSA in TLS 1.3
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — История документа
  7. IESG — Ответ на апелляцию, материал 320
  8. IANA — Параметры Transport Layer Security
  9. RFC 9847 — Обновления реестров IANA для TLS и DTLS
  10. NIST — FIPS 204, стандарт ML-DSA
  11. RFC 9881 — Идентификаторы алгоритмов ML-DSA
  12. RFC 9846 — Протокол TLS 1.3
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3