Кратко

  • 24 сентября 2026 года IESG одобрил draft-ietf-jose-hpke-encrypt-22 для публикации как Proposed Standard. Пока это Internet-Draft, а не опубликованный RFC и не свидетельство внедрения.
  • Integrated Encryption шифрует открытый текст с помощью HPKE непосредственно для одного получателя. Key Encryption защищает общий ключ шифрования содержимого и допускает получателей HPKE, ECDH и RSA в одном объекте JWE JSON.
  • Стандартный минимум требует успеха хотя бы одного получателя, но приложение решает, достаточно ли одного или нужны все. Защита общей CEK при этом ограничена самым слабым алгоритмом получателя.

Открытый текст не закрывает список обязательств

Организация адресует JWE рабочему сервису, архивному хранилищу и системе аварийного восстановления. Рабочий сервис извлекает CEK, тег содержимого проходит проверку, библиотека возвращает сообщение. Это настоящий криптографический успех.

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

Поэтому решение IESG от 24 сентября важно именно в своих границах. Редакция 22 работы JOSE по HPKE с JWE одобрена для публикации как Proposed Standard. Это факт процесса стандартизации, а не сертификат продукта, конфигурации, хранения ключей, совместимости или исполнения корпоративной политики. До завершения редакционного процесса документ также нельзя называть опубликованным RFC.

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

В Integrated Encryption HPKE шифрует само сообщение. Отдельной CEK нет, поэтому enc должен отсутствовать. Защищённый заголовок содержит alg с полностью заданным набором HPKE; ek запрещён; получатель обязан быть ровно один. JWE Encrypted Key несёт инкапсулированный секрет HPKE, а поля IV и Authentication Tag JWE пусты, поскольку соответствующая операция входит в HPKE.

В Key Encryption появляется отдельный уровень. Случайная CEK один раз шифрует содержимое согласно enc, после чего HPKE шифрует CEK для каждого HPKE-получателя. Его JWE Encrypted Key содержит HPKE ciphertext ключа CEK, а ek — инкапсулированный секрет. Recipient_structure связывает контекст JOSE, алгоритм содержимого и необязательную информацию приложения с расписанием ключей HPKE.

Так возникает поддержка нескольких получателей. В JWE JSON получатель HPKE может соседствовать с ECDH-ES+A128KW или RSA-OAEP-256. Содержимое зашифровано один раз, но каждый участник получает отдельный защищённый маршрут к одной CEK.

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

«Хотя бы один» — нижняя граница протокола

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

Для JWE JSON обработчик также должен вернуть приложению сведения, какие получатели сработали, а какие нет. Этот вектор результатов нужен для локального правила приёмки.

Пусть A успешно использует HPKE, B не проходит из-за старого ключа, а C успешно использует унаследованный алгоритм. Библиотека способна вернуть открытый текст. Приложение, которому нужен только A, может принять объект. Приложение, требующее A и B, обязано отказать. Третье приложение может отказать из-за запрещённого алгоритма C, хотя C получил CEK. Одинаковые байты не означают одинакового исполнения обязательств.

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

Самый слабый маршрут ведёт к тому же CEK

Все получатели в Key Encryption ведут к общей CEK. Любой разрешённый путь, который её раскрывает, открывает общее содержимое. Поэтому раздел Security Considerations прямо утверждает: при нескольких получателях безопасность содержимого ограничена самым слабым алгоритмом, применённым для шифрования CEK.

Это не общий запрет смешанных миграций. Это граница оценки: нельзя присвоить всему конверту свойства самого нового пути и забыть о более слабом пути к тому же ключу.

История редакции 22 показывает важность режима. Второй Working Group Last Call в JOSE касался только удаления HPKE-4-KE и HPKE-6-KE. Эти идентификаторы Key Encryption отсутствуют в редакции 22, тогда как HPKE-4 и HPKE-6 для Integrated Encryption остались. Запись «HPKE поддерживается» скрывает именно то различие, которое изменилось.

Проект также не рекомендует использовать одну пару KEM-ключей в нескольких режимах или наборах HPKE и применять один ключ для HPKE и не-HPKE алгоритмов. Аудиторский след должен связывать получателя, режим, набор, идентификатор ключа и разрешённое назначение.

Подход Heng Lu к слоям реальности помогает не смешивать документы. Одобрение IESG — институциональный факт. alg — факт формата. Успех получателя — криптографический факт. Утверждённый список и выбор между «один» и «все» — факты контроля. Наблюдаемый вердикт приложения — отдельный операционный факт.

Источники