Кратко

  • IETF обновила устав LAMPS, поручив группе сопровождать PKIX и S/MIME и работать над гибридным согласованием ключей, двойными подписями и облегчённой обработкой сертификатов.
  • Устав даёт полномочие формировать повестку, но не принимает проект, не публикует RFC, не выпускает код, не устанавливает корень доверия и не доказывает совместимость.

Самоподпись не объясняет, кому доверять

Устав приводит в пример неподписанный сертификат X.509 для передачи сведений о субъекте корня доверия. Постквантовые подписи могут быть крупными, поэтому самоподпись способна зря расходовать канал и вычисления устройства, уже получившего корень через защищённую настройку.

Корень, подписавший сам себя, не создаёт внешнего основания доверять ему. RFC 5280 рассматривает сведения о корне как входные данные проверки пути, полученные надёжной внесистемной процедурой. RFC 5914 определяет отдельное представление TrustAnchorInfo.

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

Пока это пример разрешённой темы, а не стандарт LAMPS и не отчёт о внедрении.

21 августа изменился мандат группы

21 августа 2026 года в 20:40 UTC IETF объявила о новом уставе Limited Additional Mechanisms for PKIX and SMIME. Datatracker показывает LAMPS действующей группой, а редакцию 08 — утверждённым текстом.

Группа сопровождает механизмы закрытых групп PKIX и S/MIME, в том числе CMP, CMC, EST, S/MIME и PKIX. Одновременно она готовит эти среды к алгоритмам, способным заменить RSA, Diffie-Hellman, ECDSA, ECDH и EdDSA или работать рядом с ними.

Мандат не безграничен. Для новой работы нужны известное сообщество с реальным интересом к внедрению и хотя бы один достаточно определённый подход для решения о принятии. Эти условия открывают формальное рассмотрение, но не подтверждают безопасность. Проект может провалить анализ, участники могут разойтись в политике ошибок, а группа — отказать в принятии.

Стандарт алгоритма не задаёт всю интеграцию

NIST опубликовал FIPS 203 для ML-KEM, FIPS 204 для ML-DSA и FIPS 205 для SLH-DSA. Устав допускает и алгоритмы, оценённые CFRG.

Эти стандарты не определяют самостоятельно применение в сертификатах PKIX, объектах CMS, протоколах регистрации и клиентах S/MIME. Нужны кодировки, параметры, профили, правила проверки и ошибок, тестовые векторы и реализации.

Спецификации должны использовать OID, выделенные NIST или IANA. Идентификатор позволяет назвать конструкцию, но не обновляет библиотеку и не меняет политику принятия.

Поэтому готовность к постквантовому переходу надо разложить на состояния: стандарт, профиль, OID, статус документа, код, настройка, созданный объект, принятый объект и наблюдаемый сервис.

Гибрид требует общей функции вывода

Гибридное согласование объединяет секреты традиционных алгоритмов и подходящих постквантовых механизмов. LAMPS предстоит определить форматы, идентификаторы, регистрацию и эксплуатацию.

Простого соединения значений недостаточно. Конечным точкам нужны однозначная кодировка и одинаковый вывод ключевого материала. Устав называет HKDF, метод NIST SP 800-56C или функцию, оценённую CFRG. Разделение извлечения и расширения в RFC 5869 делает соль, контекст и длину частью соглашения.

Нужно также определить результат при взломе, ошибочной реализации, подмене или пропуске компонента. Composite KEM остаётся активным Internet-Draft. Это свидетельство работы над спецификацией, а не окончательной совместимости продуктов.

Две подписи создают несколько режимов принятия

Устав охватывает двойные подписи из традиционных и постквантовых компонентов. Проект composite signatures также остаётся активным.

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

Удостоверяющий центр, генератор CMS, почтовый клиент, библиотека и приложение могут находиться в разных состояниях. Реальная работа — их пересечение. Число сертификатов с новым материалом не показывает, сохранил ли его посредник и принял ли получатель.

Месяц в уставе — часы координации

Объявление ставит composite signatures для PKIX и CMS на октябрь 2026 года, composite KEM — на ноябрь, CAA Security — на декабрь. Это ориентиры работы, а не гарантии IETF Last Call, одобрения IESG, RFC, релиза или развёртывания.

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

Институциональный график и операционные доказательства следует вести раздельно.

Полномочие устава кончается на границе группы

Устав легитимирует проблему, привлекает рецензентов и даёт документам постоянную площадку. Он не превращает LAMPS в удостоверяющий центр, регулятора алгоритмов или удалённого администратора локальных корней.

NIST отвечает за свои стандарты, назначенные органы выделяют идентификаторы, процесс IETF определяет статус документа, поставщики выпускают код, а операторы и владельцы продуктов настраивают принятие. Корень в формате RFC всё равно остаётся локальным полномочием.

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

Sources