Кратко

  • RFC 9999 задаёт самоописываемую оболочку для Evidence, Attestation Results, Endorsements, Reference Values и Appraisal Policies в RATS при передаче через CBOR, JSON, JWT, CWT, X.509, HTTP, MIME и CoAP.
  • Record, Tag и Collection CMW обеспечивают распознавание, маршрутизацию и группировку, но сами не дают аутентичности, целостности, конфиденциальности, свежести, смысловой оценки или полномочия.
  • Если Collection представляет одно составное или многоуровневое устройство, все элементы Evidence необходимо криптографически связать; отдельные действительные подписи не доказывают общую машину, эпоху и транзакцию.

После ремонта сервер запросил возврат в производственный пул. На проверку пришла Collection с тремя элементами: CPU, SmartNIC и GPU. Типы были зарегистрированы, форматы разобрались без ошибки, внутренние подписи прошли. Автоматика увидела три зелёных результата и вывела общий зелёный статус.

Но Evidence для GPU могла быть сохранена до ремонта. Evidence для SmartNIC могла принадлежать исправной резервной машине. Только отчёт CPU мог относиться к серверу, который сейчас просит доступ. Подделывать подписи не требуется: из трёх правдивых фрагментов можно составить неправдивую машину.

RFC 9999, опубликованный IETF в июле 2026 года как документ Standards Track, определяет Remote ATtestation procedureS Conceptual Message Wrapper — CMW. Спецификация решает задачу совместимости. В RATS есть несколько видов концептуальных сообщений, форматов claims, сериализаций и транспортов. Общая типизированная оболочка позволяет добавлять новую технологию аттестации без переделки ядра каждого принимающего протокола.

Это стандарт упаковки и диспетчеризации. Это не стандарт доверия к содержимому.

Три решения остаются у трёх ролей

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

CMW переносит объекты между ролями, не передавая им полномочия друг друга.

Record CMW содержит type, непрозрачный value и при необходимости индикатор ind. Индикатор может обозначать Reference Values, Endorsements, Evidence, Attestation Results или Appraisal Policy. Tag CMW выводит CBOR-тег из CoAP Content-Format по правилам RFC 9277. Collection CMW объединяет помеченные элементы и может рекурсивно включать другие Collections.

Реестр IANA RATS Parameters координирует индикаторы. RFC 9711 определяет Entity Attestation Token, а RFC 9782 — типы носителей EAT. Благодаря этому ядро выбирает подходящий handler без догадок о формате.

Выбор handler не означает доверие. Тип указывает грамматику, а не истинность claims. Индикатор Evidence описывает функцию полезной нагрузки, но не доказывает полномочия автора. Регистрация IANA предотвращает конфликт идентификаторов, но не гарантирует поддержку профиля, актуальность политики или надёжность источника.

Подпись имеет смысл только вместе с областью

RFC 9999 прямо называет CMW инкапсуляцией, а не форматом безопасности. Record, Tag и Collection сами не обеспечивают аутентичность, целостность или конфиденциальность.

Защита может находиться внутри концептуального сообщения. CBOR CMW можно защитить структурами COSE из RFC 9052, JSON CMW — JWS из RFC 7515. Защищённый канал охраняет передачу. Challenge-response может ограничить replay.

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

RFC 9781 даёт наглядный контрольный пример. UCCS — незащищённый набор claims CWT. Помещение в CMW помогает распознать и перенести его, но не создаёт аутентичность. RFC 9999 показывает, как добавить внешнюю подпись. Свойство появляется на дополнительном проверяемом слое.

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

Здоровый компонент может заменить скомпрометированный

Современное устройство составное. CPU, SmartNIC и GPU сервера могут иметь разные Attesting Environments. Маршрутизатор состоит из шасси и плат. В многоуровневой загрузке один этап измеряет следующий.

Collection CMW переносит разнородные Evidence вместе. Если она заявляет одно составное или многоуровневое устройство, RFC 9999 требует криптографически связать все сообщения Evidence. Без защиты целого объекта или внутренних связей злоумышленник может подменить Evidence скомпрометированной части Evidence от здоровой части другого устройства.

Способ связи не единственный. Можно подписать всю Collection, использовать общие идентификаторы или nonce, связать элементы взаимными подписями или хешами либо определить иной механизм в принимающем протоколе. Проверка должна ответить не «есть ли подпись», а «связывает ли проверенная область каждого члена с заявленным субъектом, топологической эпохой и транзакцией».

Не всякая Collection представляет одно устройство. Она может собирать Endorsements, Reference Values, результаты или сообщения о нескольких устройствах. Порядок записей незначим, метки уникальны лишь внутри одной коллекции. gpu или slot-3 получает точный смысл только из collection type либо assembly profile, физического инвентаря, идентификатора устройства и версии топологии.

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

Рекурсия должна иметь бюджет

Collections могут содержать Collections. Это удобно для слоёв, но увеличивает глубину parsing, число элементов, объём, Base64-обработку, криптографические проверки и внешние запросы.

RFC 9999 разрешает ограничить глубину, оставляя точный способ объявления и согласования вне своего объёма. Оператор должен задать общий размер, число членов, глубину, время handler, число криптографических операций и fan-out запросов. Успешный выбор decoder не даёт неограниченных ресурсов.

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

Для каждого принятого типа нужны версия handler, допустимые профили, политика алгоритмов, лимиты и поведение при ошибке. Тогда расширяемость не превращается в разрешение через незнание.

Криптографически действительное может быть устаревшим

После обновления firmware, замены платы или изменения Reference Values старое Evidence может сохранить действительную подпись и потерять актуальность. RFC 9334 рассматривает freshness отдельно — через синхронизированное время, nonce или epoch ID.

CMW переносит соответствующие сообщения, но не доказывает, что все элементы отвечали на один challenge. CPU с nonce A, SmartNIC с nonce B и GPU только с timestamp не образуют автоматически одну транзакцию. Это определяют assembly profile и политика Verifier.

Нужно сохранять challenge, его издателя, окно, допущения о часах, эпоху и охват элементов. «Подпись действительна» не означает «состояние текущее».

После оценки остаётся авторизация. Verifier может подтвердить соответствие firmware, а Relying Party всё равно запретить чтение данных или подпись релиза. Переносимый Attestation Result не должен становиться универсальным пропуском вне своего адресата и контекста.

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

X.509 способен превратить частное раскрытие в публичное

RFC 9999 разрешает CMW в сертификатах X.509, CSR и CRL. Это использует существующий канал PKIX, но может сделать сведения об оборудовании долговечными и широко доступными.

Заявитель может сообщить Certification Authority модель и patch level HSM для получения сертификата подписи кода, не соглашаясь раскрыть их всем получателям сертификата. RFC 5280 задаёт общий профиль сертификатов и расширений, но не создаёт такого согласия. RFC 3647 даёт структуру Certificate Policy и CPS. RFC 9999 рекомендует описать в практике условия, при которых CA может включать Evidence третьей стороны.

Минимизация claims, аудитория, срок хранения, профиль и право публикации должны решаться до выпуска. Отзыв сертификата не вернёт уже скопированные сведения.

Формальную структуру завершает реальный путь

Принцип Heng Lu о приоритете running code требует смотреть на исполнение: parser, handler, точные байты, ключи, связь, свежесть, версию политики, решение и эффект. Валидный CMW — один факт в этой цепочке.

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

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