Кратко

  • IESG одобрила draft-ietf-lamps-cms-composite-kem-03 как Proposed Standard, но документ пока остаётся Internet-Draft: его состояние — RFC Ed Queue, статус RFC Editor — blocked: Reference Not Received, а действия IANA находятся в состоянии In Progress при IANA OK - Actions Needed.
  • Блокировка не является чисто редакционной формальностью. CMS-документ нормативно ссылается на точную редакцию draft-ietf-lamps-pq-composite-kem-21, от которой получает определения Composite ML-KEM, операции KeyGen/Encaps/Decaps, представление публичных ключей в X.509 и алгоритмические OID. Этот companion-документ пока имеет статус IESG Evaluation::Revised I-D Needed, два DISCUSS и незавершённую работу IANA.
  • Уже выделенные в реестре IANA SMI идентификаторы 55–65 показывают прогресс в пространстве алгоритмических OID, но не доказывают завершение CMS-модуля, финальность всех назначений, публикацию обоих RFC или готовность конкретных продуктов к совместной эксплуатации.
  • Операционный контроль распределён между несколькими слоями: IESG, авторами зависимого черновика, RFC Editor, IANA, разработчиками реализаций, поставщиками сертификатов и операторами, решающими, какие комбинации разрешать. Поэтому «стандарт одобрен» и «система безопасно включена в продакшене» — разные состояния.
  • Для закупок и production-gating полезнее простого номера RFC будет проверяемая companion-dependency receipt: запись, связывающая точные версии и хеши двух спецификаций, статусы IESG/RFC Editor/IANA, окончательные назначения, поддержку обеих сторон, результаты двусторонних тестов и правила fallback/rollback.

Что именно произошло 18 сентября

Protocol Action завершила важную часть процесса IETF для CMS-документа: IESG согласилась с продвижением draft-ietf-lamps-cms-composite-kem-03 как Proposed Standard.

Это означает значительно больше, чем просто наличие рабочего черновика. Но это всё ещё не RFC.

Текущая последовательность состояний хорошо показывает разницу. Datatracker помещает CMS-документ в RFC Ed Queue. RFC Editor одновременно отмечает его как blocked: Reference Not Received. Для IANA состояние действий — In Progress, а review state — IANA OK - Actions Needed.

Эти метки описывают разные процессы, которые нельзя сворачивать в один бинарный признак «готово».

Одобрение IESG говорит о результате стандартизационного рассмотрения данного документа. RFC Ed Queue говорит о переходе к публикационной обработке. Статус RFC Editor сообщает, что публикация сейчас ждёт необходимую ссылочную зависимость. Статусы IANA показывают, что регистрационные действия ещё выполняются.

Для бизнеса это различие существенно. Поставщик может начать инженерную подготовку после одобрения IESG, но использовать само одобрение как доказательство финального wire-format, полного набора назначений, совместимости с другим продуктом или production-readiness нельзя.

Companion-документ превращает публикацию в цепочку зависимостей

draft-ietf-lamps-cms-composite-kem-03 специально построен как companion к draft-ietf-lamps-pq-composite-kem-21.

Разделение ответственности между ними принципиально.

Базовый Composite ML-KEM-документ определяет криптографические комбинации и операции, на которых строится CMS-профиль. Именно туда CMS-документ делегирует определения KeyGen, Encaps и Decaps, представление Composite ML-KEM ключей в X.509 и идентификаторы соответствующих алгоритмов.

CMS-документ не переопределяет этот слой заново. Он задаёт, как уже определённые Composite ML-KEM механизмы помещаются в инфраструктуру CMS: использование KEMRecipientInfo, правила для сертификатов, объявления возможностей через SMIMECapabilities и связанные параметры обработки.

Это хорошая архитектура спецификаций — но она создаёт реальную публикационную зависимость.

Нормативная ссылка зафиксирована именно на draft-ietf-lamps-pq-composite-kem-21. Сам -21 пока находится в состоянии IESG Evaluation::Revised I-D Needed; Datatracker показывает два DISCUSS, а действия IANA ещё не завершены.

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

Placeholder — это маленькая строка с большим операционным смыслом

Особенно наглядно зависимость проявляется в ASN.1.

В CMS-черновике остаются RFC Editor placeholder-ы. Один из них связан с номером собственного CMS ASN.1-модуля, другой — TBDCompositeMOD — должен быть заменён номером, который получит id-mod-composite-mlkem-2025 из companion-документа.

То есть CMS-модуль буквально импортирует объект из другого ещё не завершённого модуля и не может окончательно зафиксировать соответствующую ссылку, пока не будет известно назначение для зависимости.

Это не означает, что вся криптографическая конструкция находится в неопределённости. Но это показывает, почему состояние blocked: Reference Not Received нельзя трактовать как несущественную задержку издательского оформления.

Существует конкретный объект зависимости, который должен пройти собственные редакционные и регистрационные этапы.

Для команд, генерирующих ASN.1-код, фиксирующих OID в конфигурациях или формирующих production-профили, это важная граница: предварительные значения, имена и структура документа могут быть достаточны для разработки и тестов, но артефакт сборки должен сохранять происхождение этих значений и не маскировать черновой статус под окончательное назначение.

Уже зарегистрированный OID — не то же самое, что завершённая спецификация

Ситуацию дополнительно усложняет то, что часть инфраструктуры идентификаторов уже существует.

В реестре IANA SMI присутствуют идентификаторы 55–65 для ряда Composite ML-KEM алгоритмов. При этом запись реестра ссылается на более раннюю редакцию draft-ietf-lamps-pq-composite-kem.

Именно здесь особенно легко сделать слишком сильный вывод: если OID уже виден в официальном реестре, может показаться, что весь нормативный пакет завершён.

Но это разные утверждения.

Наличие алгоритмического идентификатора означает существование конкретного регистрационного факта. Оно само по себе не сообщает, что:

  • зависимый документ получил окончательное одобрение;
  • все его DISCUSS закрыты;
  • пересмотренный Internet-Draft больше не требуется;
  • завершены все связанные действия IANA;
  • ASN.1-модули получили окончательные номера;
  • RFC Editor опубликовал оба документа;
  • конкретная реализация поддерживает данный OID;
  • две независимые реализации одинаково кодируют, объявляют и обрабатывают эту комбинацию;
  • оператор разрешил её в production-политике.

Поэтому OID — это важный элемент идентичности алгоритма, а не сертификат готовности всей цепочки.

От RFC 9629 к работающему CMS-профилю

CMS-спецификация строится поверх уже опубликованного RFC 9629, который определяет KEMRecipientInfo и общий способ применения KEM в CMS.

Операционный поток можно представить как несколько связанных уровней.

Получатель имеет KEM-публичный ключ, обычно связанный с сертификатом. Отправитель использует соответствующий механизм инкапсуляции и помещает результат в KEMRecipientInfo. Общий секрет далее участвует в выводе ключа, который используется для защиты ключевого материала CMS.

Composite ML-KEM добавляет к этой схеме не просто ещё одно строковое имя алгоритма. CMS-профиль должен корректно идентифицировать конкретную composite-комбинацию, получить ключ из сертификата в ожидаемом представлении, вызвать совместимую реализацию Encaps/Decaps, сформировать правильный KEMRecipientInfo и, если применяется объявление возможностей, корректно представить поддержку через SMIMECapabilities.

Отсюда появляется важное различие между поддержкой алгоритма и поддержкой протокольного пути.

Библиотека может реализовать Composite ML-KEM, но не уметь использовать его через CMS. CMS-стек может знать KEMRecipientInfo, но не понимать конкретный Composite ML-KEM OID. Сертификатный стек может не уметь импортировать соответствующий ключ. Отправитель может поддерживать комбинацию, которую получатель не объявляет или не декодирует.

Даже наличие всех функций по отдельности ещё не доказывает сквозную совместимость.

Семь состояний, которые нельзя смешивать

Для управленческих решений полезно рассматривать переход как минимум через семь отдельных ворот:

Состояние Что оно действительно показывает Чего оно не доказывает
Одобрение IESG Стандартизационное решение по документу Публикацию RFC
Очередь RFC Editor Документ передан в публикационный процесс Отсутствие блокирующих зависимостей
Завершение IANA Требуемые регистрационные действия выполнены Поддержку в продуктах
Финальные алгоритмы и OID Зафиксирована нормативная идентичность механизмов Корректную реализацию
Поддержка реализации Один продукт способен обработать механизм Совместимость с независимым продуктом
Двусторонняя интероперабельность Конкретные версии двух сторон успешно взаимодействуют Готовность всех продуктов и конфигураций
Production enablement Оператор разрешил механизм в определённой среде Универсальную пригодность или отсутствие будущих изменений

Именно последовательное прохождение этих ворот создаёт доказательство, пригодное для эксплуатации.

Сокращать её до «Proposed Standard → можно включать» экономически удобно только на бумаге. В реальной системе стоимость ошибки переносится на сертификатную инфраструктуру, управление версиями, откат, диагностику несовместимых сообщений и возможную повторную выдачу credential-ов.

Код и hackathon: ценный сигнал, но ограниченный

В материалах IETF отмечены реализационная работа и тестирование на hackathon. Это существенно лучше спецификации, которая существует только как текст: код способен обнаруживать расхождения в ASN.1, порядке полей, API-предположениях и обработке тестовых векторов.

Но такое свидетельство необходимо правильно ограничивать.

Успешный код не означает, что все реализации используют тот же путь. Hackathon не представляет все библиотеки, HSM, CMS-клиенты, CA, S/MIME-стеки и корпоративные middleware-продукты. Проверенная комбинация алгоритмов не доказывает все остальные комбинации. Один сертификатный сценарий не проверяет все варианты цепочек, расширений и политик.

Даже интероперабельность двух реализаций является утверждением о конкретных версиях, настройках и тестовом диапазоне.

Поэтому подобные результаты следует хранить не как абстрактное утверждение «interoperable», а как воспроизводимый тестовый артефакт: кто с кем взаимодействовал, какие версии использовались, какие комбинации были проверены, какие сертификаты участвовали и какие тестовые векторы подтверждают результат.

Консенсус WG — не измерение рыночного спроса

Рабочая группа достигла консенсуса по документу. Это важное свойство процесса IETF: спецификация получила достаточную поддержку для продвижения.

Однако консенсус WG не является статистическим исследованием внедрения и не доказывает универсальный спрос на каждую composite-комбинацию.

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

В результате рынок может быть формально стандартизирован, но операционно фрагментирован: один продукт поддерживает X25519-комбинацию, другой — только конкретную ECDH-конфигурацию, третий умеет ключи, но ещё не CMS, а четвёртый оставляет функциональность выключенной политикой.

Поэтому закупочная спецификация должна перечислять необходимые комбинации и сценарии явно, а не ограничиваться требованием «поддерживать Composite ML-KEM».

Companion-dependency receipt как проверяемое доказательство

Для управления такой цепочкой имеет смысл ввести машиночитаемую companion-dependency receipt — квитанцию зависимости между документами и реализациями.

Она не заменяет RFC. Её задача — показать, какой именно набор нормативных и эксплуатационных состояний стоял за решением о тестировании или включении.

Минимальная запись должна содержать:

  • точные имена версий обоих документов — например, CMS -03 и companion -21 — и криптографические хеши полученных файлов;
  • время фиксации и состояния IESG, RFC Editor и IANA для каждого документа;
  • точную нормативную ссылку из CMS-документа на companion;
  • все связанные RFC Editor placeholder-ы и их текущие либо окончательные значения;
  • происхождение каждого используемого алгоритмического OID: реестр, номер, документ и редакцию, на которую указывает регистрация;
  • состояние DISCUSS, требуемых редакций и других открытых действий companion-документа;
  • после публикации — окончательные номера RFC и финальные назначения IANA;
  • конкретные Composite ML-KEM комбинации, которые поддерживает реализация;
  • поддержку KEMRecipientInfo и используемых KDF/key-wrap параметров;
  • способность создавать и разбирать нужные сертификатные представления;
  • поддержку и обработку SMIMECapabilities;
  • точные версии программного обеспечения на стороне отправителя и получателя;
  • идентификаторы тестовых векторов, corpus либо иные воспроизводимые входные данные;
  • направление теста: A→B и отдельно B→A;
  • область тестирования сертификатных цепочек и CMS-типов;
  • production-политику: где механизм разрешён, предпочтителен или запрещён;
  • правила fallback, включая условия, при которых более слабый или прежний механизм может быть выбран;
  • процедуру rollback и сохранение способности прочитать ранее созданные объекты;
  • критерии выхода из пилота и условия, при которых механизм допускается в production.

Такой receipt превращает размытое заявление «мы протестировали новый стандарт» в проверяемую запись происхождения.

Экономика зависимости: стоимость появляется после криптографии

Главный операционный риск здесь не обязательно заключается в математике Composite ML-KEM. Он возникает на стыках организаций и жизненных циклов.

IESG контролирует стандартизационное продвижение. Авторы и рабочая группа должны разрешить открытые замечания зависимого документа. IANA контролирует регистрационные назначения. RFC Editor управляет публикационной связностью документов. Поставщики решают, какие комбинации реализовать. CA и PKI-команды определяют выпуск совместимых сертификатов. Операторы задают policy.

Ни одна сторона не контролирует весь путь.

Именно поэтому преждевременная фиксация одной редакции в продукте создаёт последующие расходы. Если меняется нормативная зависимость, приходится сопоставлять implementation behavior с финальным текстом. Если меняется ASN.1-модуль, необходимо проверить генераторы и декодеры. Если разные поставщики расходятся по набору поддерживаемых комбинаций, появляется матрица совместимости. Если алгоритм включается до готовности rollback, эксперимент превращается в миграционное обязательство.

Раннее тестирование при этом вполне рационально. Нерационально другое: потерять сведения о том, что именно тестировалось, а затем считать старый успешный результат подтверждением совместимости с финальными RFC.

Источники