Кратко

  • draft-ietf-cose-hpke-27 разрешает передавать ciphertext отдельно от COSE_Encrypt или COSE_Encrypt0, оставляя в структуре nil. Позднее наложенные COSE-подпись или MAC не охватывают эти внешние байты.
  • AEAD способен обеспечить их целостность, но успешный tag не равен публичной аутентификации отправителя, решению об авторизации или доказательству выполненного действия.
  • На 1 октября 2026 года редакция 27 оставалась Internet-Draft в состоянии IESG AD Evaluation::AD Followup. Три реализации проверяли примеры, а не производственную цепочку хранения конкретной системы.

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

Редакция 27 COSE-HPKE проводит жёсткую границу. Если COSE_Encrypt или COSE_Encrypt0 использует отделённый шифротекст, последующая защита через COSE_Sign, COSE_Sign1, COSE_Mac или COSE_Mac0 его не охватывает. Реализация обязана обеспечить целостность отделённых данных самостоятельно.

nil означает внешний маршрут

RFC 9052 допускает отдельную передачу содержимого COSE. В позиции payload или ciphertext находится nil, а приложение предоставляет байты по другому пути. Так удобнее хранить большие объекты и разделять жизненный цикл метаданных и данных.

В интегрированном режиме HPKE выдаёт ct. Текст редакции 27 позволяет поместить его в COSE_Encrypt0 либо передать отдельно. В режиме шифрования ключа слой 0 шифрует содержимое ключом CEK, а слой 1 шифрует CEK для каждого получателя. XML-источник описывает ту же модель.

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

У каждой проверки свой предмет

Внешняя подпись проверяет точные байты Sig_structure; MAC — соответствующую структуру под общим ключом. Данные не попадают в вычисление только потому, что интерфейс показывает их внутри одной карточки.

AEAD слоя 0 может защищать отделённый шифротекст. При правильных CEK, nonce и associated data валидный tag обнаруживает изменение. Это сильное утверждение о целостности под симметричным ключом, но не публичное утверждение о личности отправителя.

HPKE Open даёт следующий результат — обработку для ключа получателя. Разрешение kid связывает ссылку с версией ключа. Затем политика идентичности определяет principal, авторизация решает допустимость операции, а commit фиксирует эффект.

Квитанция Что установлено Что остаётся открытым
Внешняя подпись/MAC Покрытые байты валидны под ключом Входил ли внешний blob в вычисление?
AEAD Шифротекст и AAD целостны под CEK Кто является публичным отправителем?
HPKE Open Капсуляция обработана для получателя Имел ли отправитель полномочия?
Идентичность Ключ связан с доверенным principal Разрешено ли текущее действие?
Авторизация Политика разрешает операцию Произошёл ли commit?
Эффект Внешнее состояние изменилось Связан ли результат со всей цепочкой?

Контекст получателя связывает соседние слои

Recipient_structure включает алгоритм следующего нижнего слоя и защищённые заголовки получателя в HPKE info. Тем самым алгоритм контентного шифрования связывается с механизмом, защищающим CEK.

Структура кодируется детерминированно по RFC 8949. Отправитель и получатель независимо строят значение, которое не передаётся как готовый объект. Разная сериализация одинаковых смыслов разрушила бы проверку. Детерминизм решает представление байтов, но не право владения ключом, неизменяемость blob или авторизацию.

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

Рекомендуемый kid помогает выбрать статический публичный ключ получателя и при защищённом размещении входит в key schedule. Но это идентификатор, а не удостоверение. Одинаковые короткие значения возможны в разных пространствах имён; cache может вернуть старый ключ; аварийный ключ может расшифровать сообщение, не представляя нужную рабочую роль.

Шифрование для получателя не идентифицирует отправителя

RFC 9180 задал известную модель HPKE. Активный проект-преемник заменит его в случае утверждения, но пока остаётся работой в процессе. В реестре внедрения нужны версия, режим и suite, а не только слово HPKE.

Base mode не аутентифицирует отправителя внутри KEM. COSE-подпись или MAC могут добавить аутентификацию, если проверена их фактическая область. RFC 9338 различает подтверждение зашифрованных данных и утверждение о plaintext. Если нужна санкция на смысл, её необходимо строить явно.

RFC 9053, реестр COSE IANA и реестр HPKE координируют алгоритмы и номера. Зарегистрированный код не сертифицирует настройки продукта, ротацию ключей или бизнес-политику.

Зрелость документа и доказательство эксплуатации

Datatracker показывал редакцию 27 как документ рабочей группы COSE с целью Proposed Standard, переданный IESG и находившийся в AD Evaluation::AD Followup 1 октября 2026 года. История датирует редакцию 12 сентября. Номера RFC ещё не было.

Отчёт shepherd говорит о широком обсуждении и о трёх независимых реализациях, которыми авторы проверяли примеры к IETF 125. Это полезное свидетельство running code, но не аудит неизменяемости хранилища, внешнего контекста, отзыва ключей и авторизации конкретного продукта.

Манифест фактического покрытия

Для каждой операции храните: полные байты COSE; тип и tag; защищённые и незащищённые заголовки; признак embedded/detached; неизменяемый locator, длину и хэш шифротекста; хэш входа подписи/MAC; алгоритм AEAD, хэш AAD и результат tag; режим и suite HPKE; хэши ek и Recipient_structure; происхождение дополнительного контекста; namespace kid и версию ключа; результат Open; хэш plaintext внутри доверенной границы; идентичность; авторизацию; commit ID; наблюдаемый эффект.

Не нужно писать приватные ключи или лишний plaintext в журнал. Хэшей, версионированных ссылок и квитанций решений достаточно. Отсутствие покрытия тоже факт: outer_signature_covers_blob=false может быть безопасно при доказанном AEAD, но не должно превращаться в расплывчатое signed=true.

Minimum Initial Specification поддерживает малый общий манифест при локальной бизнес-политике. Running-Code Primacy требует смотреть на реальные буферы. The Policy Mirror показывает власть defaults хранилища и resolver. Reality Layers разделяет синтаксис, байты, доказательство, личность, разрешение и эффект.

Источники