Кратко

  • Когда приложение, ОС, прошивка и аппаратная часть принадлежат разным поставщикам, общего списка доверенных Endorser недостаточно.
  • Подпись поставщика ОС может быть подлинной, но его утверждения об аппаратуре всё равно могут выходить за пределы мандата.
  • Версия 11 разрешает хранить связь полномочий в политике, Evidence или обоих источниках, поэтому результат должен фиксировать реально применённую связь.

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

RATS Endorsements 11 рассматривает эти части как отдельные Target Environments. Каждый поставщик может добавлять claims о своей среде. Но Verifier обязан различать, какому Endorser разрешено предоставлять Endorsement о какой среде. Пример проекта прямой: поставщику ОС можно доверять в вопросах ОС, но не аппаратной части.

Сертификат подтверждает источник и целостность. Он не подтверждает предметную компетенцию. Если реализация превращает «доверенный подписант» в разрешение на все слои, криптография работает, а граница полномочий исчезает.

Проект не задаёт единственного места для этой связи. Она может находиться в Appraisal Policy for Evidence. Evidence может назвать допустимого Endorser для слоя. Источники могут сочетаться. Поэтому подписанной Endorsement недостаточно для полного воспроизведения решения.

Два Verifier могут получить одинаковое сообщение и разойтись из-за разных карт слоёв, версий политики или делегирования внутри Evidence. Если журнал сохранил лишь подпись, аудитор узнает автора, но не основание допуска его claims.

RFC 9334 разделяет роли: Endorser поставляет claims; Verifier Owner управляет политикой оценки Evidence; Relying Party Owner решает, как действовать по Attestation Result. Происхождение, оценка и действие — разные поверхности управления.

Условная Endorsement тоже не выдаёт полномочия. Её правило сопоставления определяет применимость claims, а не итоговую надёжность устройства. Оно не позволяет Endorser говорить за любой слой. Безошибочное совпадение может допустить claim из неверной области ответственности.

Поиск правильного ключа не закрывает вопрос. UEID из RFC 9711 способен помочь найти материал проверки, но версия 11 оставляет конкретным протоколам гранулярность применимости ключа — экземпляр, класс или иные claims. Правильный ключ не означает правильный слой.

Минимальная проверяемая цепочка включает свежесть Evidence; личность, цепочку и статус Endorser; идентификатор и карту Target Environment; правило, разрешающее этому субъекту этот слой и класс claims; выбранную версию Endorsement; идентичность Verifier и политики; решение Relying Party и наблюдаемый эффект.

История Datatracker показывает версию 11 в IESG Evaluation и в повестке на 8 октября 2026 года. Различия между 09 и 11 доступны для проверки. Текст версии 11 остаётся Internet-Draft, а не RFC.

CoRIM 11 даёт конкретный контекст модели данных. Его применение само по себе не доказывает, что реализация сохранила и обеспечила правильную область полномочий.

Источники