Кратко

  • Редакция 05 проекта-преемника HPKE была загружена 25 сентября. На следующий день IESG открыла голосование по одобрению, перевела документ в оценку и включила его в заседание 8 октября. RFC 9180 пока не заменена новым опубликованным стандартом.
  • RFC 9180 содержит Base 0x00, PSK 0x01, Auth 0x02 и AuthPSK 0x03; новый проект определяет первые два режима, а значения последних двух резервирует. Это уже было сделано в редакции 04.
  • Поле Auth в реестре KEM оставлено ради интерфейса RFC 9180, хотя проект-преемник его не использует. Наличие поля не показывает, какие приложения вызывают старые режимы и какую проверку личности они обещают.

После принятия нового документа можно обновить ссылку в реестре и в документации библиотеки. Но такой административный шаг не отвечает на вопрос, который задаёт получатель сообщения: чем подтверждается отправитель? В HPKE существуют разные ответы. Старый RFC 9180 помимо базового шифрования описывает режимы, использующие асимметричный ключ отправителя. Проект, который должен его сменить, пришёл на голосование IESG без этих режимов. Поэтому слово «преемник» здесь нужно читать с точными границами, а не как обещание полной функциональной замены.

Таблица режимов проводит границу без расплывчатых формулировок. Значения 0x00 и 0x01 остаются у Base и PSK; 0x02 и 0x03, ранее отведённые Auth и AuthPSK, помечены как зарезервированные. Приложение к проекту прямо перечисляет удаление двух последних режимов среди отличий от RFC 9180. Одновременно авторы намерены сохранить одинаковое поведение там, где функция описана обоими документами. Общая часть должна совпадать, но это не означает, что новый документ продолжает определять каждую функцию старого. Режим PSK подтверждает владение заранее общим секретом, так что утверждение «аутентификации больше нет» неверно. Однако общий секрет не тождественен доказательству владения статическим закрытым ключом отправителя в прежнем Auth.

Важно не приписывать это изменение последней редакции. Таблица редакции 04 уже резервировала два значения. Новое событие датировано 26 сентября: после публикации редакции 05 IESG создала бюллетень, начала оценку и назначила обсуждение на 8 октября. На момент проверки требовались дополнительные позиции участников голосования, а IANA должна была пересмотреть обновлённый текст. Заголовок проекта говорит об отмене действия RFC 9180 лишь при одобрении. Ни завершённого решения, ни опубликованной RFC-преемницы эти события пока не дают.

В мартовском сопровождении документа Martin Thomson объяснил позицию рабочей группы без языка запрета. По его словам, старые аутентифицированные режимы применяются ограниченно, а подходящей постквантовой поддержки в рамках нынешней конструкции нет. Группа с некоторым сожалением исключила их из этой итерации. При этом он признал существующих пользователей, назвал решение отсрочкой, а не отказом от режимов, и допустил их возвращение после дальнейшей работы. Это качественное свидетельство о мотивах группы, а не проверенная статистика внедрений или объявление об уязвимости.

Раздел IANA показывает, почему новый библиографический статус не равен новой картине программного обеспечения. Проект предлагает после утверждения заменить ссылки на RFC 9180 в реестрах HPKE, оставив прежние записи и коды KEM. В форме регистрации KEM остаётся логическое поле Auth, обозначающее поддержку AuthEncap() и AuthDecap() из RFC 9180. Сам новый текст подчёркивает, что это поле ему не нужно и сохранено для совместимости. Запись не является журналом вызовов: она не говорит, использует ли конкретный клиент Auth, допускает ли его партнёр и какой смысл приложен к успешной расшифровке.

Daniel Kade предлагает проверять зависимость там, где она существует: у каждого приложения записать версию документа, используемый режим, обещанную проверку отправителя, возможности второго участника обмена и результат испытаний. Затем ответственный за продукт может сознательно сохранить путь RFC 9180, изменить аутентификацию на уровне протокола или ждать дальнейшей стандартизации. Это аналитическая рекомендация, не требование IETF и не утверждение о случившемся сбое. Успешная расшифровка сама по себе ещё не доказывает, что прежнее заявление о личности отправителя пережило обновление.

Источники