Кратко

  • RFC 9999 вводит общую самодекларируемую оболочку для Evidence, Endorsements, Reference Values, Attestation Results и Appraisal Policies.
  • Формы Record, Tag и Collection задают структуру и тип, но сами по себе не обеспечивают подлинность, целостность, конфиденциальность, единство составного устройства или разрешение доступа.
  • Если Collection представляет одно составное устройство, все элементы Evidence должны быть криптографически связаны; затем Verifier выполняет оценку, а Relying Party принимает прикладное решение.

Представим сервер, который должен войти в закрытый кластер. Центральный процессор сообщает о цепочке загрузки, SmartNIC — о своей прошивке, GPU — о состоянии отдельной аттестующей среды. Служба сбора помещает три объекта в Collection CMW и передаёт их проверяющей стороне.

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

Именно эту границу показывает RFC 9999, опубликованный в июле 2026 года как документ Standards Track IETF. RATS Conceptual Message Wrapper даёт концептуальным сообщениям общую переносимую форму для разных протоколов и сериализаций. Обёртка помогает доставить и направить объект, но не делает его содержание истинным.

Тип сообщения не равен его оценке

RFC 9334 разделяет роли. Attester создаёт Evidence. Verifier сопоставляет его с Endorsements, Reference Values и Appraisal Policy for Evidence и выдаёт Attestation Result. Relying Party применяет собственную Appraisal Policy for Attestation Results и выбирает прикладное действие.

RFC 9999 закрепляет пять позиций индикатора: Reference Values, Endorsements, Evidence, Attestation Results и Appraisal Policy. Record CMW содержит медиатип или CoAP Content-Format, сериализованное значение и при неоднозначности битовую карту ind.

Индикатор отвечает на вопрос, какому обработчику передать байты. Он не отвечает, можно ли им доверять. Reference Value может устареть, Endorsement — исходить от непринятого ключа, подлинное Evidence — выйти из окна свежести, Attestation Result — быть созданным по другой политике.

Ядро CMW может не разбирать внутренний формат, а передавать непрозрачное значение подключаемому модулю. Это полезная расширяемость и одновременно предел полномочий. Демультиплексор распоряжается маршрутом объекта. Он не получает права допустить сервер к ресурсу.

Collection — дерево, а не доказательство единства

CMW образует дерево. Record и Tag являются листьями; Collection объединяет помеченные элементы и может содержать другие Collection. Разные форматы CPU, SmartNIC и GPU можно перевозить вместе, не переписывая внешний протокол для каждой аппаратной комбинации.

Но стандарт разрешает смешивать в Collection разные концептуальные сообщения и материалы о нескольких устройствах. Поэтому наличие контейнера не означает «полный набор для одной машины». Необязательное значение __cmwc_t в виде URI или OID задаёт общий тип и пространство имён меток. Оно может описать допустимую сборку, но без защиты остаётся утверждением о структуре.

Рекурсивность требует ещё одного локального соглашения — максимальной глубины. Пограничный шлюз, читающий один уровень, и Verifier, принимающий четыре, способны увидеть разные смыслы в одном объекте. Глубина, размер, число членов, неизвестные типы и поведение при отказе должны быть согласованы в принимающем протоколе.

Для трёх подписей всё равно нужна общая связь

RFC 9999 прямо говорит, что CMW не является форматом безопасности. CBOR CMW можно подписать COSE_Sign1, JSON CMW — JWS; CMW можно поместить в claim cmw токена CWT или JWT. Это доступные механизмы, а не свойства по умолчанию.

Когда Collection переносит Evidence одного составного или многоуровневого устройства, все элементы обязаны иметь криптографическую связь. Можно подписать всю Collection. Можно использовать общие идентификаторы и nonce, перекрёстные подписи или хеш-связи. Attester, который создаёт Collection, отвечает за целостность её состава.

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

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

Новый носитель создаёт новую границу доверия

RFC 9999 регистрирует application/cmw+cbor, application/cmw+json, application/cmw+cose и application/cmw+jws, а также claims JWT/CWT и расширение X.509. Одно сообщение может пройти через веб-API, ограниченный протокол, сертификат или файл.

У каждого носителя своя область защиты. JWS может охватывать Collection, но не Evidence, извлечённое и сохранённое отдельно. JWT подтверждает издателя внешнего токена, но не всех внутренних производителей. TLS защищает канал, а не происхождение пересылаемого объекта. Перекодирование CBOR в JSON может сохранить смысл и уничтожить подпись точных байтов.

Принимающий протокол обязан определить допустимые типы и комбинации, нужную защиту, интерфейс и взаимодействие моделей безопасности. Фраза «payload — CMW» выбирает синтаксис, но не распределяет ответственность.

В X.509 последствия видны особенно ясно. Расширение CMW обычно не следует помечать critical. Но если оно необходимо для доступа и старый клиент мог бы его проигнорировать, critical допустим. Этот бит решает, остановится ли неосведомлённая Relying Party или продолжит без условия аттестации.

Сертификат также расширяет аудиторию. Evidence может раскрывать персональные данные, модель HSM и уровень обновлений. Передача этих данных удостоверяющему центру не означает согласия на многолетнюю публикацию. RFC 9999 требует ясной практики сертификации, если CA собирается включать стороннее Evidence в публичный сертификат.

Attestation Result не является командой доступа

Положительный результат Verifier легко превратить в универсальное «разрешить». Архитектура RATS противостоит этому: Verifier Owner определяет оценку Evidence, а Relying Party Owner — применение результата к конкретному действию.

Один действительный результат может разрешать телеметрию, требовать карантина для управления и быть недостаточным для операции подписи. Запрошенная возможность, зона, срок и исключение относятся к контексту Relying Party.

Воспроизводимая запись связывает, но не сливает: Evidence и способ связи; версии Endorsements и Reference Values; политику Verifier и результат; политику Relying Party и запрос; финальное действие. Один Boolean стирает причину. Один токен стирает субъекта, который распорядился доступом.

Принцип Lu Heng о приоритете работающего кода задаёт дисциплину: формальное соответствие обёртки важно как происхождение, но не может отменить фактическое поведение обработчиков, Verifier и контроля доступа. Minimum Initial Specification поддерживает тонкую общую грамматику. Связывание, комбинации и последствия остаются локальными решениями. Reality Layers разделяет тип, подпись, оценку и выполненное действие.