Кратко

  • Шесть media types различают EAT в CWT и JWT, отделённые bundles в CBOR/JSON и незащищённые claims sets в CBOR/JSON; дополнительно зарегистрированы +cwt и номера CoAP.
  • Внешний eat_profile помогает маршрутизатору до разбора тела, однако требует сравнения с внутренним claim и выполнения полного профиля.
  • Успешный parse, проверенная оболочка, достойные доверия claims, appraisal Verifier и разрешение Relying Party — разные утверждения.

Стандартный вход в неодинаковые формы

Архитектура RATS разделяет роли: Attester выпускает Evidence, Verifier оценивает его и создаёт Attestation Results, Relying Party использует результат в собственной политике. RFC 9782 не объединяет эти решения. Он даёт API общий словарь для представлений, которые переходят между ролями.

Зарегистрированы application/eat+cwt, application/eat+jwt, два типа detached EAT bundle и два типа UCCS/UJCS. Тем же шести формам соответствуют CoAP Content-Formats 263–268. Суффикс +cwt сообщает универсальному ПО о базовом синтаксисе CWT. Gateway может раньше отклонить неподдерживаемую форму, согласовать ответ через Accept и выбрать узкий parser.

Но суффикс не сообщает подписанта, допустимый алгоритм, ключ, обязательные claims, механизм свежести или политику. Тип bundle не доказывает совпадение отделённых наборов с digest в защищённом token.

UCCS и UJCS показывают разницу особенно ясно. RFC 9781 требует аутентифицировать отправителя защищённого канала и обеспечить целостность; для конфиденциальности нужна и аутентификация получателя. После выхода claims set из канала его гарантии прекращаются. Хранение или пересылка — новая граница. Полный CWT, прошедший по этому каналу, всё равно опирается на собственную COSE-оболочку: канал его не заверяет.

Идентификатор профиля выбирает правила, а не подтверждает их

Профиль EAT ограничивает варианты сериализации, вложения, COSE/JOSE, алгоритмов, идентификации ключей, bundles, claims и freshness. Внутри EAT его называет eat_profile. RFC 9782 разрешает вынести тот же URI или OID в параметр media type, чтобы router выбрал профильный процессор без просмотра тела.

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

Совпадение тоже не равно conformant. RFC 9711 запрещает eat_profile для partial profile. Full profile должен позволять conforming receiver декодировать, проверить и установить свежесть любого EAT от conforming sender. Правильный URI может сопровождать запрещённый algorithm, пропущенный claim или ошибочный nonce. Имя загружает перечень проверок; результат создаёт только исполнение.

Сначала реальные байты

RFC 9782 называет media types лишь подсказками приложению. Оно обязано проверить соответствие данных ожидаемому формату независимо от объявления и прекратить обработку при ошибке. Иначе возможны privilege escalation и cross-protocol attack. RFC 9110 аналогично предупреждает об опасном content sniffing, а RFC 8725 требует явных типов и взаимоисключающих правил для разных JWT.

Поэтому первая квитанция содержит header и hash тела, вторая — route, handler и parser, третья — envelope, algorithm, key, trust anchor и результат либо область аутентифицированного канала. Detached bundle требует отдельной сверки каждого digest.

Затем оцениваются claims. RFC 9711 задаёт их смысл, но не уровень защиты измеряющего компонента. Верная подпись связывает байты с ключевой моделью, но не делает измерение истинным. Verifier учитывает реализацию, endorsements, reference values и policy.

Freshness — самостоятельное обязательное условие против replay. Аутентичный token может быть старым. Наконец, Verifier формирует Attestation Results, а Relying Party отдельно решает действие для конкретного ресурса. Положительная оценка может закончиться отказом из-за времени, риска или иных требований.

Полная последовательность: внешний type/profile → bytes → handler → protection → внутренний profile/claims → conformance/freshness → appraisal → action. IANA создаёт общий символический язык; running code, отрицательные тесты и наблюдаемые переходы превращают его в операционную реальность — именно эту границу подчёркивает Heng Lu.

Источники