Кратко

  • Призыв RATS к принятию draft-poirier-rats-eat-da-10 заканчивается 11 сентября 2026 года. Он спрашивает, должна ли группа взять индивидуальный проект в работу; это не итог принятия, не RFC и не инструкция по развёртыванию.
  • Device Assignment Token может переносить свидетельства об устройстве. Он не выбирает дополнительные ограничения, не оценивает свидетельства, не задаёт политику полагающейся стороны и не разрешает использование устройства.

Призыв относится к рабочему документу, а не к допущенному устройству

Публичный объект назван точно: десятая редакция An EAT Profile for Trustworthy Device Assignment. Datatracker по-прежнему показывает его как активный Internet-Draft и кандидата на работу RATS, а не как одобренный IETF документ с формальным нормативным статусом. До 11 сентября вопрос узок: должна ли группа работать над текстом? Последующее решение может изменить состояние рабочего пункта, но не сертифицирует сетевой адаптер, GPU или виртуальную функцию для конкретной нагрузки.

Сценарий при этом существенен. Назначение устройства позволяет доверенной ВМ управлять сетевым адаптером, GPU или функцией PCIe, хотя гипервизор и другие ВМ могут лежать вне её границы доверия. Проект требует свидетельств об идентичности устройства, прошивке и конфигурации и определяет DAT как профиль EAT для их представления.

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

Дополнительные ограничения не находятся в токене

В проекте прямо сказано, что формат основан на информации SPDM и не вводит дополнительных ограничений безопасности. Описать, выбрать и применить их по операционным требованиям должны другие субъекты. Это не пробел, который можно заполнить предположением, будто формат уже решил вопрос безопасности. Это место, где остаётся локальный контроль.

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

Текущий охват также требует осторожности: внимание сосредоточено на PCIe-устройствах с SPDM; устройства SPDM на кристалле оставлены на будущее, а живая миграция доверенной ВМ не охвачена. Формат с такими собственными границами нельзя выдавать за универсальный вывод о безопасности любого назначения устройств.

Результат проверяющего не есть авторизация

RFC 9334 отделяет оценку Evidence, которую Verifier выполняет с опорными значениями, подтверждениями и своей политикой, от оценки Attestation Results полагающейся стороной. Последняя применяет собственную политику для прикладного решения, включая авторизацию. Эти две политики могут принадлежать и настраиваться разными ответственными владельцами.

RFC 9711 проводит ту же границу. EAT может описывать сущность для решения о доверии, но не задаёт нормативных правил обработки для проверяющих. Verifier вправе пересылать, изменять или дополнять утверждения по своей политике; полагающаяся сторона должна понимать эту обработку до толкования результата. Действительная подпись и корректный профиль описывают артефакт, а не переносимое распоряжение допустить устройство.

Устав RATS включает в работу форматы и процедуры для свидетельств и результатов, но оставляет за её пределами форматы и протоколы политик оценки. Это не недостаток стандартизации: так общий формат может перемещаться, не притворяясь выбором допустимого риска для каждой организации.

Два свидетельства, две ответственности

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

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

Источники

  1. Призыв RATS к принятию
  2. Запись проекта в Datatracker
  3. draft-poirier-rats-eat-da-10
  4. Устав RATS
  5. RFC 9334
  6. RFC 9711