Summary

  • draft-ietf-cose-hpke-27 опубликован 12 сентября и остаётся на этапе доработки по замечаниям директора области. Это Internet-Draft в Standards Track, а не RFC и не утверждённый профиль внедрения.
  • Защищённый psk_id выбирает режим PSK; без него действует Base. Он шифрует для владельца закрытого ключа получателя, но не аутентифицирует отправителя в KEM HPKE.
  • kid указывает на ключ получателя, а не на личность отправителя. Daniel Kade предлагает сохранять ограниченную квитанцию фактической аутентификации и авторизации без PSK и открытого текста; это редакционное предложение, а не требование IETF.

Успешное открытие не устанавливает автора

Редакция 27 появилась 12 сентября. История Datatracker показывает состояние AD Evaluation::AD Followup после передачи документа в IESG для публикации в Standards Track. В новой версии усилено требование к случайности: HPKE нужен криптографически стойкий источник, а в Key Encryption так же должна генерироваться ключевая величина для шифрования содержимого.

Это нормативное уточнение, но не завершение стандарта. Текущая запись может меняться, номера IANA пока предполагаемые, итогового RFC нет. Тем не менее граница уже видна: успешная криптографическая операция и установленная полномочная личность — разные факты.

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

Схема шифрования и способ доверия выбираются отдельно

Проект описывает Integrated Encryption и Key Encryption. В первом HPKE непосредственно защищает открытый текст в COSE_Encrypt0 для одного получателя. Во втором содержимое шифруется отдельным ключом, а HPKE оборачивает этот ключ в слое получателя; схема поддерживает нескольких адресатов.

Каждый предлагаемый идентификатор алгоритма COSE фиксирует полный набор KEM, KDF и AEAD и допустимую схему. Это уменьшает риск незаявленного смешения компонентов и применения идентификатора не в том слое.

Способ аутентификации задаётся иначе. При наличии защищённого psk_id выбирается mode_psk, при отсутствии — mode_base. Сам проект подчёркивает, что режим явно не содержится в идентификаторе ciphersuite.

Поэтому одинаковый номер алгоритма может сопровождать разные утверждения. PSK подтверждает владение внешним общим секретом. Base такого утверждения не делает. Если журнал хранит лишь номер алгоритма, в нём нет поля, которое выбрало путь доверия.

kid помогает выбрать ключ адресата

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

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

psk_id также не равен PSK. Идентификатор защищён, а секрет передаётся как внешний ввод и не должен попадать в объект COSE. Владение секретом не определяет автоматически человека, действующую роль или разрешение. Текущий проект HPKE требует высокой энтропии и предупреждает, что слабый пароль не становится подходящим PSK после обработки функцией вывода ключа.

Связанный контекст ещё нуждается в политике

Защищённые заголовки и внешние аутентифицированные данные позволяют включить контекст в криптографическую операцию. В Key Encryption детерминированная Recipient_structure связывает алгоритм следующего слоя, защищённые заголовки получателя и дополнительные сведения. Так устраняется возможность подмены алгоритма на границе слоёв.

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

HPKE намеренно остаётся низкоуровневым механизмом. Защита от повторов вне упорядоченного контекста, предотвращение downgrade, потеря сообщений и свежесть принадлежат окружающему протоколу. Повторно поданный single-shot объект может снова пройти криптографическую проверку. Недопущение повторного действия требует состояния приложения.

Отделённый шифртекст создаёт ещё одну границу. Добавленная затем подпись COSE или MAC не обязательно покрывает вынесенные байты. Проект требует отдельно обеспечить их целостность. Запись «подпись верна» недостаточна без области её действия.

Base — допустимый выбор, если он сделан сознательно

Конфиденциальный публичный ящик может принимать анонимные отправления. Другой протокол может аутентифицировать отправителя в отдельном слое. Проект прямо называет COSE_Sign, COSE_Sign1, COSE_Mac и COSE_Mac0 способами добавить аутентификацию.

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

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

Сохранить причину принятия

Daniel Kade предлагает квитанцию аутентификации отправителя для каждого принятого объекта. Она фиксирует версию проекта или профиля, Integrated либо Key Encryption, ciphersuite, фактический режим HPKE, отпечаток ключа получателя и происхождение его распространения. Для PSK добавляются односторонний отпечаток psk_id, несекретная версия ключа и состояние жизненного цикла. Для Base указывается отдельная подпись, MAC, канал или прикладная проверка — либо прямо отмечается разрешённая анонимная подача.

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

Такой документ не требуется проектом, RFC 9052, RFC 8937 или реестром COSE IANA. Это организационное доказательство, отделяющее результат механизма от власти в духе Policy Mirror Heng Lu. Минимальная начальная спецификация оставляет общий след компактным, а редакционная дисциплина BTW не позволяет представить обновление проекта свидетельством инцидента.

Sources

  1. COSE HPKE, редакция 27
  2. COSE HPKE, редакция 26
  3. Текущая запись Datatracker
  4. История документа
  5. HPKE, редакция 04
  6. RFC 9052 — структуры и обработка COSE
  7. RFC 8937 — улучшение случайности
  8. Реестр COSE IANA
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists