Кратко

  • RFC 9597 регистрирует параметр 15: карту утверждений CWT в заголовках COSE для зашифрованной, отделённой или вообще не-CWT нагрузки.
  • Ранний issuer может выбрать каталог ключей, но этот выбор остаётся временным до криптографической проверки и должен быть отменён при неуспехе.
  • Одинаковые утверждения в заголовке и CWT-нагрузке обычно должны совпадать; совпадение не доказывает истинность, полномочие ключа, приватность или право выполнить действие.

Шлюз получает зашифрованный COSE-объект. Payload пока недоступен, но issuer виден. По нему шлюз выбирает каталог, получает кандидатов и резервирует очередь. Затем подпись не проходит.

Безопасность определяется тем, что случилось с ранним выбором. Если исчезли очередь, cache и временная привязка к tenant, это действительно была гипотеза. Если issuer уже стал постоянной учётной идентичностью, итоговая проверка отказала байтам, но не отменила созданную ими реальность.

RFC 9597 стандартизует место для CWT-утверждений в любом COSE-объекте. Это нужно для шифрования, detached signature и нагрузки, которая не является CWT Claims Set или даже CBOR. Спецификация делает данные доступными раньше, но не переносит доверие на более ранний этап.

Одна карта разделяет два пространства номеров

COSE-параметры и CWT-ключи используют компактные целые числа. Прямое смешение вызвало бы коллизии. Поэтому в реестре IANA COSE появилась запись «CWT Claims» с меткой 15; внутри находится карта с ключами из реестра CWT.

RFC 8392 определяет issuer, subject, audience, expiration, not-before, issued-at и token identifier. RFC 8610 даёт CDDL-описание формы. Реестры и схема решают вопрос имени и кодирования, но не говорят, какие утверждения обязательны для endpoint и кто вправе их делать.

Параметр можно использовать с нагрузкой, которая не является CWT. Подписанное изображение или firmware может вынести issuer наружу для поиска ключа. Наличие карты не идентифицирует внутренний формат. Значение и последствия задаёт локальный профиль.

Защищённый заголовок не равен разрешённому действию

RFC 9052 делит заголовки на protected и unprotected. RFC 9597 рекомендует protected, поскольку unprotected-карта изменяема, и разрешает параметр только один раз на обеих сторонах.

Получатель не вправе считать рекомендацию фактом. Профиль должен решить, отвергается ли метка 15 в unprotected-карте или допускается лишь как недоверенная подсказка. Иначе совместимый fallback незаметно становится политикой безопасности.

Даже protected-карта доказывает лишь участие конкретных bytes в успешной криптографической операции с ключом. Нужно отдельно установить, имел ли ключ право представлять этого issuer для данного класса объектов, подходит ли audience, действительны ли сроки и разрешена ли операция.

Защищать нужно и интерпретацию. RFC 9597 рекомендует typ из RFC 9596, если естественного контекста недостаточно. Тип выбирает договор проверки, договор интерпретирует claims. Защищённое значение под изменяемым селектором не даёт защищённого решения.

Ранний выбор обязан быть обратимым

Поиск ключа по issuer — полезная необходимость. Получателю может понадобиться утверждение, чтобы найти ключ, которым оно будет проверено. Этот круг разрешает ограниченный поиск, но не выдаёт полномочия.

Непроверенный issuer может выбрать namespace поиска, изолированную очередь или небольшой бюджет. Он не должен окончательно создавать tenant, наполнять общий cache, выбирать биллинг, запускать неограниченный fan-out или менять внешнее состояние.

Предварительная квитанция хранит исходные bytes, положение метки 15, значение, ветвь, запрос и кандидаты. Финальная добавляет криптографический результат, источник интерпретации, версию профиля, сравнение с payload, audience, сроки, локальную политику, действие и эффект.

RFC 9597 предупреждает о риске обработки до криптографической целостности и требует подтверждать предварительные решения после завершения. Негативные тесты должны сочетать успешный lookup с неверной подписью, правильный issuer с неверным type и другой detached payload. В каждом случае раннее состояние должно исчезнуть.

Принцип Heng Lu о первичности работающего кода здесь строг: обещание проверить позже слабее наблюдаемого rollback.

Две копии не должны создавать две власти

RFC 7519 предусмотрел похожее копирование для JWT/JOSE. RFC 9597 требует, чтобы одинаковое утверждение в заголовке и CWT payload имело одинаковое значение, если приложение не задало другую конкретную процедуру.

Сверка не позволяет gateway искать ключ по issuer A, а приложению авторизовать issuer B. Исключение обязано назвать потребителя каждой копии, её защиту, причину допустимого различия и версию профиля. Иначе решение невозможно воспроизвести.

Совпадение не означает истинность. Обе копии могут быть просрочены, адресованы другой audience или подписаны некомпетентным ключом. Явные правила RFC 8725 нужны и после равенства.

Видимость до расшифрования — это раскрытие

Claim снаружи шифрования не зашифрован. Issuer может раскрыть организацию, subject — человека или устройство, audience — целевой сервис, identifier — устойчивую корреляцию. Копирование всех claims ради observability способно разрушить конфиденциальность без взлома алгоритма.

Профиль должен спросить, какое минимальное значение нужно ранней задаче, кто видит его в сети, proxy, queue, log, trace, cache и ошибках, как долго оно хранится и может ли краткоживущий routing realm заменить стабильный subject. Валидная подпись не является согласием на публикацию.

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

Отделённый payload удлиняет цепочку

COSE может защищать отдельно передаваемый контент, но RFC 9052 возлагает неизменность транспорта на приложение. Правильный issuer не доказывает, что verifier получил нужный файл.

Следует хранить locator, контекст получения, точные bytes или hash и результат связывания. Иначе правильная ранняя подсказка может соединиться с содержимым другой транзакции.

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

Источники