Кратко

  • Редакция 01 проекта Authenticated Provenance for WIMSE Delegation Chains связывает соседние входные и выходные дайджесты, а агрегированная подпись не позволяет незаметно вычеркнуть подписавшего посредника, даже если тот не менял тело.
  • Почти постоянным остаётся лишь размер агрегата. WIT, элементы Signature-Input, прежние path и query, параметры и материалы непрерывности добавляются на каждом переходе.
  • Успешная проверка устанавливает представленный набор подписантов и подписанные ими преобразования. Она не подтверждает обязательный состав маршрута, полномочия, правильность действия, commit приложения или внешний результат.

Где именно произошло преобразование

В цепочке программных агентов исходное поручение редко проходит без изменений. Планировщик уточняет задачу, инструмент добавляет данные, прокси меняет URI, шлюз передаёт тело без изменений. Последний сервис видит итоговый HTTP-запрос, но не все предыдущие представления.

draft-reddy-wimse-aggregate-signatures-01 предлагает сохранить проверяемое происхождение этой последовательности. Редакция 01 опубликована 28 сентября 2026 года и остаётся активным индивидуальным Internet-Draft. Это не RFC, не документ рабочей группы WIMSE, не консенсус IETF, не отчёт о совместимости и не свидетельство внедрения. Указанный авторами желаемый Standards Track не меняет текущего статуса.

Первая часть механизма строит связь между входом и выходом каждого участника. В wimse-req-digest он подписывает дайджест полученного тела, а в Content-Digest — отправляемого. Инициатор помечает вход зарезервированным значением origin. Проверяющая сторона сопоставляет подписанный выход одного перехода с подписанным входом следующего.

Если H2 изменил тело, то после удаления H2 выход H1 не совпадёт со входом H3. Разрыв показывает место утраты, а пара «до — после», подписанная H2, приписывает преобразование этому workload. Приписывание не означает одобрения. Ошибочный либо недобросовестный сервис способен подписать внутренне последовательное, но запрещённое изменение.

Дайджесты тела также не равны полной HTTP-подписи. Метод, path, query, выбранные поля и сам дайджест входят в подписываемую базу каждого перехода. Для проверки приходится восстановить именно эту базу.

Вторая часть — Signature-Aggregate. Каждый workload формирует подпись своей базы, после чего отдельные значения сворачиваются в один накопительный результат. Получатель проверяет агрегат не сам по себе, а против упорядоченного набора пар «публичный ключ — реконструированное сообщение».

Это закрывает иной пробел. Пусть H2 переслал тело без изменений. Непрерывность дайджестов H1 и H3 сохранится даже после исключения H2. Если подписи передавались отдельно, запись и подпись H2 можно было бы убрать вместе. Из агрегата его вклад нельзя просто вырезать: проверка по списку без H2 завершится неудачей.

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

Короткое значение требует длинного контекста

Редакция 01 прямо отделяет размер подписи от размера доказательства. Signature-Aggregate близок к одной подписи при любой длине цепочки, но Signature-Input, Workload-Identity-Tokens и дайджесты растут вместе с числом участников.

Для каждого перехода нужны уникальная метка, перечень покрытых компонентов, параметры создания и срока действия, nonce, tag и audience, удостоверение workload, входной дайджест, сохранённые wimse-req-path и wimse-req-query, выходной дайджест и порядок соседних записей.

Workload-Identity-Tokens определён как словарь Structured Fields, где ключом служит метка подписи. Новый участник сохраняет ранее полученные элементы, проверяет префикс, выбирает новую метку, добавляет свой WIT и подписывает соответствующий элемент. Замена или удаление прежнего токена изменит покрытое значение.

Из WIT берутся заявленная идентичность sub и публичный ключ cnf.jwk. Но перенос токена ещё не является его валидацией. До обработки сообщения необходимо проверить издателя, audience, срок, привязку ключа, домен доверия и допустимость алгоритма. Наличие удостоверения доказывает только наличие предъявленного объекта.

Реконструкция зависит и от URI, которых уже нет в финальном запросе. Один сервис мог подписать /review?scope=a, другой отправить /apply?scope=b. Поэтому каждый переход сохраняет собственные исходящие path и query в подписанных параметрах. Проверяющий использует их, а не подставляет последний URI во все исторические базы.

Выходной Content-Digest перехода восстанавливается из подписанного входного дайджеста его преемника. Для последнего перехода берётся финальный Content-Digest. Метод и content type читаются из конечного сообщения, потому что проект запрещает менять их по цепочке; изменение разрушит реконструкцию прошлых подписей.

Таким образом, доказательство имеет форму S + Σ(W + I + D + R): один агрегат, плюс WIT, данные Signature-Input, дайджесты и значения реконструкции каждого перехода. Это объяснительная модель Daniel Kade, а не замер производительности. Точный объём зависит от длины токенов и URI, алгоритма, меток, сериализации Structured Fields и сжатия заголовков.

Общий отказ не называет неисправного участника

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

Поэтому допуск и диагностика требуют разных записей. Просроченный WIT, утраченный path, повреждённый дайджест или ключ, запрещённый локальной политикой, остановит весь запрос. Для локализации понадобятся защищённые локальные журналы, квитанции по префиксам, повторная проверка отдельных компонентов или контролируемое воспроизведение. Универсального протокола blame редакция 01 не задаёт.

Политика алгоритмов тоже не сжимается. Все участники агрегата должны использовать совместимую агрегируемую схему. Проект указывает BLS message augmentation как возможную текущую реализацию, но идентификатор для WIT оставляет отдельной спецификации. BLS не обладает постквантовой стойкостью. Записанный идентификатор не заменяет локальный allowlist, границу доверия и защиту от downgrade.

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

Подписанный ответ ещё не является фактом исполнения

Ответ может защищаться в обратном направлении. Его источник задаёт wimse-resp-digest="origin", последующие переходы подписывают полученное и отправленное представления и добавляют вклад в агрегат. Если ответ проходит без подписи, этот механизм не гарантирует обнаружение подмены или удаления.

Даже полностью проверенный ответ подтверждает происхождение заявления, а не внешний эффект. Для записи в базу, перевода актива, предоставления доступа или изменения production нужен идентификатор commit и независимое наблюдение результата.

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

Источники

Источники зафиксированы 30 сентября 2026 года по времени Asia/Shanghai. В них нет измеренного overhead, совместимой реализации, реальной атаки, производственной экономии, результата conformance или наблюдаемого ущерба. Статья не объявляет конкретный workload злоумышленником и не выдаёт индивидуальный проект за внедрённый стандарт.