Кратко

  • Редакция -07 индивидуального Internet-Draft draft-schrock-ep-authorization-evidence-chain от 28 сентября выделяет VERIFIED и ACCEPTED из одного прежнего результата. Это не утверждённый стандарт IETF.
  • Не найденный по ссылке ключ означает NOT_EVALUATED, а не проваленную подпись. Найденный ключ ещё не принят для соответствующей роли и момента времени.
  • После обеих положительных проверок остаются сопоставление с ожидаемым действием и достаточность доказательств; SATISFIED не является решением исполнителя AUTHORIZED или подтверждением результата.

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

Изменение описано в тексте Ian Schrock Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence. Официальный архив содержит версию -07 с датой 28 сентября 2026 года. Это индивидуально поданный Internet-Draft с намерением автора выпустить информационный документ, а не принятый рабочей группой стандарт, RFC или отчёт о работающей системе. Сама модель составной цепочки доказательств была уже в -06. В перечне изменений -07 сказано точнее: старое VERIFIED объединяло собственную проверку артефакта с доверием полагающейся на него стороны. Теперь технический результат называется VERIFIED, а принятие по закреплённым параметрам доверия — ACCEPTED.

Нативный проверяющий должен подтвердить криптографическую и структурную целостность компонента. Только после этого сторона, принимающая доказательство, оценивает свой каталог ключей и состояние его записей, допустимых издателей, классы ключей, роли и аудиторию, собственную политику формата и её версию. Эти входные данные не назначаются предъявителем пакета. Особый случай — документ, называющий ключ по ссылке. Если ссылка не разрешается средствами принимающей стороны, криптографическую проверку нельзя провести; следует записать NOT_EVALUATED с причиной, а не объявлять FAILED. Если ключ найден, проверка становится возможной, но право ключа подтверждать именно это утверждение в нужное время всё ещё требует отдельного принятия.

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

Присланное агентом сериализованное заключение — новое доказательство, которое ещё надо проверить.

После положительных VERIFIED и ACCEPTED появляется отдельный вопрос: относится ли подлинная, принимаемая бумага к действию, которое исполнитель действительно подготовил? Для этого служит MATCH. Документ надёжного издателя, описывающий другое действие, не совпадает с ожидаемым; ошибку нельзя приписывать подписи или статусу издателя. Далее проверяются срок, аутентифицированное состояние, ограничения ролей и связи между точными артефактами. SATISFIED означает только выполнение указанного принимающей стороной требования к доказательствам на момент оценки. AUTHORIZED — собственное решение приложения, контролирующего операцию. Был ли вызов и каков его эффект, нельзя вывести ни из того, ни из другого статуса.

В -07 предложен воспроизводимый протокол с версией алгоритма EP-AEC-EVALUATOR-07-v1, хешами цепочки, ожидаемого действия и требования, временем, хешем снимка доверия, а также отдельными native_verification и acceptance по каждому компоненту. Коды причин должны различать неудачную проверку, невозможность её провести, отказ принять доверие и несовпадение действия. Такой журнал позволяет выяснить, поменялись ли доказательство, ключевые материалы, местная политика или само запрошенное действие. Но это выход оценки, а не предъявляемая агентом лицензия. Проект не предлагает универсального реестра или действий для IANA.

Источники