Summary

  • Индивидуальный Internet-Draft предлагает RATS-совместимому Identity Document Service выдавать по приемлемому Attestation Result обычный ключ, токен или удостоверение для полагающихся сторон, которые RATS не понимают.
  • После выдачи возникает разрыв жизненного цикла: удостоверение остаётся приемлемым по собственным правилам, хотя Evidence, политика оценки, местоположение или важное утверждение уже изменились.
  • Daniel Kade предлагает «аренду аттестации для удостоверения», связывающую срок и штатный отзыв с эпохами доказательств, версиями политик, классами утверждений, ключом нагрузки и событиями изменений. Это редакционное предложение, а не консенсус IETF.

Два истинных ответа после одного перемещения

Для обнаружения проблемы не нужен злоумышленник. Рабочая нагрузка предоставляет Evidence, Verifier оценивает его, а Identity Document Service (IDS) принимает результат и выдаёт удостоверение. Канал может быть защищён, закрытый ключ оставаться внутри нагрузки, все подписи — успешно проверяться. Затем оркестратор штатно переносит выполнение.

draft-bdnr-rats-trustworthy-credentials-02 приводит точную границу: при живой миграции из Германии во Францию утверждение Country=Germany способно стать ложным, тогда как Region=Europe останется истинным. Европейское полномочие, возможно, сохранится. Право, обусловленное обработкой в Германии, потребует пересмотра. Одно физическое событие не даёт одного ответа для всех полномочий.

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

Малый радиус изменений — содержательное требование

Многие существующие клиенты и серверы не способны обрабатывать RATS Evidence и Attestation Results. Это могут быть сторонние бинарные компоненты, неподходящие языковые среды, системы после дорогой регуляторной проверки или продукты, которыми распоряжаются разные команды. Требование переделать каждую полагающуюся сторону поставило бы внедрение в зависимость от самого неподвижного приложения.

Черновик предлагает посредника: Credential Broker, Key Broker или Credential Authority одновременно играет роль RATS Relying Party и IDS. Нагрузка подтверждает состояние ему; если результат удовлетворяет политике, посредник возвращает Identity Document, уже знакомый сотрудничающим системам. Под этим понимаются ключ, токен или удостоверение, короткого либо длительного действия. Описаны варианты ключевого брокера, заранее предоставленного удостоверения с доказательством владения и выдачи нового PoP-удостоверения либо краткосрочного bearer-токена.

Сокращение радиуса внедрения приносит реальную пользу. Существующие пути TLS, PKI и токенов продолжают работать. Закрытый ключ можно оставить у нагрузки, а чувствительное Evidence не распространять среди всех приложений.

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

У доступа появляются три времени

RFC 9334 отделяет Appraisal Policy for Evidence у Verifier от Appraisal Policy for Attestation Results у Relying Party. Первая политика толкует Evidence и формирует результат. Вторая решает, достаточно ли результата для конкретной цели. Подлинный Attestation Result сам по себе не равен разрешению.

Свежесть ограничена. Evidence должно быть достаточно новым для сценария, а результат нельзя использовать после его срока действия. RFC одновременно признаёт неизбежную гонку: состояние среды или политика могут измениться сразу после выпуска результата. Окно действия задаёт предел, но не останавливает изменения внутри него.

Выданное удостоверение заводит третьи часы. У сертификата есть notBefore и notAfter, у токена — срок, у механизма статуса — частота обновления. Старой службе доступны именно эти часы, но не эпоха Evidence и не версии двух политик. Если удостоверение действует восемь часов, а важному утверждению доверяют пять минут, преобразование не превращает пять минут в восемь часов. Оно лишь прячет разницу.

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

Верная подпись может сохранить устаревший смысл

JWS по RFC 7515 подтверждает целостность объекта и подпись соответствующим ключом. Проверка пути по RFC 5280 учитывает издателей, имена, ограничения, время и настроенный отзыв. Proof of Possession показывает контроль закрытого ключа. Ни одна из этих операций не повторяет оценку Evidence, предшествовавшую выдаче.

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

Роль IDS после выпуска не заканчивается. Он связал динамическую сторону — Evidence, reference values, Endorsements, Verifiers и политики — со стороной срока, ротации, introspection и отзыва. Связь должна сохраниться как оперативное состояние, способное вызвать действие. Запись в архиве, которую прочтут после инцидента, не прекращает доступ.

Утверждения стареют по-разному

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

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

Карта зависимостей удерживает систему от двух крайностей. Полный отзыв после любого изменения превращает аттестацию в источник простоев и побуждает скрывать сигналы. Бездействие до срока сохраняет полномочия после утраты оснований. Проверяемый ответ должен показывать, какое утверждение поддерживало какую способность и почему последовали замена, сужение, приостановка либо обоснованное отсутствие действия.

Личность нагрузки не определяется посредником доставки

Черновик допускает EST-клиента в гипервизоре или оркестраторе за пределами trusted computing base рабочей нагрузки. Клиент может аутентифицироваться ради канала. Но его необязательная личность не должна определять, удостоверение какой нагрузки возвращать: связь устанавливают Evidence и attestation, а закрытый ключ должен оставаться у нагрузки.

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

LAMPS-драфт об аттестации CSR показывает соседнюю ответственность. Если CA или RA использует attestation, она отвечает за связь нескольких утверждений друг с другом и с открытым ключом в запросе; требования следует документировать в Certification Practice Statement. Это помогает назначить владельца связи, но не доказывает, что жизненный цикл в trustworthy credentials уже решён.

WIMSE также разделяет удостоверение, представляющее личность нагрузки, и механизм доказательства владения. Контроль ключа отвечает, кто предъявляет. Он не подтверждает, что место, измерение и политика на момент выдачи остаются актуальными.

Аренда между аттестацией и удостоверением

Daniel Kade предлагает IDS вести аренду связи между аттестацией и удостоверением. Это не новый публичный формат и не требование обучить старую службу RATS. Это минимальное состояние и управляющий путь между двумя режимами действительности.

Сначала аренда фиксирует идентификатор и вид удостоверения, личность нагрузки, удерживаемый ею открытый ключ и PoP-связь. Затем — эпоху и предел свежести Evidence, Verifier, версию его Appraisal Policy for Evidence и версию политики IDS, принявшей Attestation Result. При смене Verifier или политики затронутые объекты можно найти, а не ждать случайного обновления.

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

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

Наконец, события получают перевод. Миграция, ротация ключа, новая политика, изъятие reference value, изменение ПО, неудачная коррекция или новое Endorsement могут вызвать повторную аттестацию. Следствием станет замена, сужение, приостановка, отзыв или мотивированное бездействие при несущественной перемене. IDS должен доказать не только решение, но и доступность штатного сигнала каждой категории служб.

Отзыв должен дойти до последнего решения

Пометка revoked в базе не доказывает прекращение использования. Одни службы кэшируют статус, другие проверяют его только при установке соединения, третьи ждут естественного истечения короткого токена. Уже открытый сеанс может продолжиться. Аренда должна указывать реальный путь применения и максимальную задержку.

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

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

Границы доступных свидетельств

Trustworthy-credentials draft прямо оставляет вопросы открытыми. Путь bearer-токена требует другого протокола или расширения, а /serverkeygen — дополнительной проработки. Документ требует взаимно аутентифицированных конфиденциальных каналов с защитой целостности и безопасного хранения ключей, но не задаёт полного управления после выдачи.

На дату исследования это индивидуальный Internet-Draft без формального статуса IETF. Материалы LAMPS и WIMSE тоже остаются рабочими черновиками. Источники не доказывают конкретное внедрение, типичный срок, миграционный инцидент, нарушение закона, производительность или распространение. Вступительный случай использует предупреждение самого draft и не обвиняет оператора. Предложенная аренда — редакционное руководство, а не стандарт.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-bdnr-rats-trustworthy-credentials-02
  5. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/
  6. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/history/
  7. https://author-tools.ietf.org/iddiff?url1=draft-bdnr-rats-trustworthy-credentials-01&url2=draft-bdnr-rats-trustworthy-credentials-02
  8. https://www.rfc-editor.org/rfc/rfc9334.html
  9. https://www.rfc-editor.org/rfc/rfc9711.html
  10. https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-29
  11. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02
  12. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08
  13. https://www.rfc-editor.org/rfc/rfc7030.html
  14. https://www.rfc-editor.org/rfc/rfc5280.html
  15. https://www.rfc-editor.org/rfc/rfc7515.html