Кратко

  • draft-ietf-hpke-hpke-05, находящийся на IESG Evaluation, определяет Base 0x00 и PSK 0x01, а 0x02 и 0x03, ранее назначенные RFC 9180 режимам Auth и AuthPSK, делает резервными.
  • Статус документа, наличие кода, разрешение в конфигурации, фактический выбор режима, чтение архива, совместимость партнёра и результат приложения — разные свидетельства.

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

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

Поэтому удаление из текста — основание начать учёт, а не готовая квитанция о завершении.

Сначала — точный статус проекта

Datatracker датирует редакцию 05 26 сентября 2026 года. Это активный Internet-Draft рабочей группы HPKE, нацеленный на Proposed Standard, переданный в IESG и находящийся на оценке. Он включён в повестку telechat 8 октября; после смены версии требуется повторная проверка IANA.

В заголовке сказано, что документ сделает RFC 9180 устаревшим в случае утверждения. Условие ещё действует. В зафиксированных источниках нет окончательного решения IESG и нового RFC.

Удаление Auth/AuthPSK не является новшеством именно редакции 05. В редакции 04 от июля уже были те же резервные значения и тот же пункт в списке различий. Новость состоит в стадии текущего проекта, а не в сентябрьском появлении решения.

RFC 9180 — Informational RFC потока IRTF. Его кандидат на замену претендует на IETF Proposed Standard. Процесс может определить следующий общий контракт, но не провести аудит всех прежних реализаций.

Совместимость обещана только для пересечения

Приложение A говорит, что поведение должно оставаться тем же там, где его определяют оба документа. Base и PSK входят в это пересечение.

Auth и AuthPSK больше не входят. RFC 9180 назначает им 0x02 и 0x03 и описывает функции со статическим ключом отправителя. Проект резервирует значения и удаляет варианты. Безусловное слово «обратно совместим» скрывает именно тот участок, который требует перехода.

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

Запись о совместимости должна называть редакцию, режим, suite, сборку, API, роль ключа, профиль приложения и контрагента. Общая отметка «HPKE работает» недостаточна для отключения.

Универсального реестра режимов внутри ciphertext нет

HPKE встраивается в другие протоколы. Проект оставляет приложению перенос enc, psk_id и иных несекретных параметров. Если у получателя несколько ключей, механизм выбора тоже определяет приложение.

Режим и suite задаются контекстом реализации. Нет единого самодокументируемого конверта HPKE, открытый заголовок которого можно найти во всех продуктах и получить полный реестр.

Один профиль выбирает отдельную функцию API, другой фиксирует режим в версии объекта, третий использует конфигурацию или согласование. Перехват пакетов может увидеть ciphertext, но не путь настройки. Поиск исходников может найти символ Auth, но не факт выполнения.

Отрицательный результат тоже требует границ. Статическая линковка, vendored-копии, оборудование, recovery-образ, спящий worker и старый контейнер могут не попасть в основной репозиторий.

Завершение строится из независимых квитанций

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

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

Обновление пакета не заменяет эту цепочку. Новый пакет может быть установлен, пока старый процесс остаётся в памяти. Перезапуск может сохранить исключение. Закрытие исключения не мигрирует архив. Успешный PSK-canary не охватывает редкого партнёра.

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

Индивидуальный проект показывает ветку, а не консенсус

draft-ms-hpke-auth-modes-01 предлагает вернуть AuthPSK как строгое расширение. Механика Auth возвращается как компонент, но самостоятельный Auth не возвращается, поскольку не даёт квантовой стойкости.

Datatracker прямо указывает: это индивидуальный Internet-Draft без одобрения IETF и формального статуса в процессе стандартизации. Он не является утверждённым запасным маршрутом.

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

Переписка HPKE и JOSE фиксирует дискуссии о подписях, неявной аутентификации, Key Encryption и постквантовом переходе. Это первичные свидетельства мнений, а не консенсуса, распространённости или инцидента.

Владение PSK не называет единственного субъекта

Кандидат сохраняет sender authentication для режима PSK в криптографическом смысле: сторона, построившая корректный контекст, владеет общим секретом.

Один PSK может быть у процесса, кластера или множества устройств. Его распределение, область, ротация и связь с идентичностью приложения находятся вне HPKE. Владение не превращается автоматически в бизнес-полномочие.

Проект перечисляет и нецели: отсутствие прикладной защиты от replay и downgrade, порядка и потерь сообщений, сокрытия длины, защиты от плохой эфемерной случайности и forward secrecy при последующей утрате приватного ключа получателя.

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

Последний сохранённый объект удерживает старый читатель

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

Раннее удаление ключей и декодера создаёт необратимую потерю доступности. Бессрочное сохранение пути без изоляции, владельца и срока превращает временную совместимость в постоянную поверхность риска.

Реестр должен содержать формат, окно создания, версию профиля, идентификатор ключа, срок хранения и последний тест нового чтения. Если историческая система не сохранила метаданные режима, неопределённость остаётся результатом аудита; форму ciphertext нельзя выдавать за уверенность.

Документ задаёт цель, измерение подтверждает переход

Принципы Minimum Initial Specification и Running-Code Primacy Хэн Лу разделяют публикацию и принятие. Изменение становится реальным для участника через реализацию, проверку, развёртывание и использование. Непринятие оставляет другой набор совместимости.

Это не спор со стандартом. Проект может уменьшить общее ядро HPKE. Оператор должен доказать переход локальными данными, проверкой партнёров и результатами.

Надёжный итог перечисляет изученные профили и сборки, закрытые исключения, мигрированные или уничтоженные объекты, проверенных партнёров и период без старого пути. Всё вне охвата остаётся неизвестным.

Источники