Кратко

  • Редакция draft-reddy-wimse-aggregate-signatures-01 датирована 28 сентября и остаётся активным индивидуальным Internet-Draft, а не RFC или принятым рабочей группой WIMSE стандартом.
  • Дайджесты входа и выхода обнаруживают исчезновение узла, который изменил содержание. Если он переслал запрос без изменений, соседние дайджесты могут по-прежнему совпадать.
  • Предложенная агрегированная подпись призвана закрепить и такого участника; она не подтверждает его полномочия, порядок нескольких неизменивших сообщение узлов или итог работы приложения.

Представим маршрут из трёх рабочих нагрузок. Вторая принимает запрос, подписывает и передаёт третьей без изменения тела. Если её отдельную подпись потом убрать из перечня, выход первой всё ещё совпадёт со входом третьей. По содержанию маршрут цел, по участникам — нет. Приложение A к проекту специально разбирает этот случай. Он показывает, почему отсутствие расхождения между дайджестами не означает отсутствия пропущенного посредника.

Документ называется Authenticated Provenance for WIMSE Delegation Chains. В Datatracker редакция -01 проходит как активный индивидуальный Internet-Draft без RFC stream, со статусом IESG I-D Exists; карточка предупреждает, что индивидуальная подача не означает поддержки IETF. Идея агрегировать подписи была уже в редакции -00 от 8 сентября. Текущая версия яснее объясняет, чем запись преобразований отличается от записи участия, а также подробнее рассматривает путь, строку запроса и ответы. Указанное авторами намерение работать на Standards Track не превращает текст в одобренный стандарт.

Базовый проект HTTP Message Signatures для WIMSE связывает идентичность отправителя с сообщением для следующего непосредственного получателя. Из этого не следует, что последний получатель длинной цепочки сможет проверить всех предшественников. Индивидуальное дополнение предлагает подписывать дайджесты тела при приёме и отправке, а также значения пути и query. Если один узел изменил тело, его удаление нарушит соответствие между оставшимися соседями. Это помогает отнести изменение к подписанту, но не показывает, был ли новый текст правдивым или допустимым.

Для неизменившего запрос посредника предлагается Signature-Aggregate. Вклады участников объединяются в одно значение, а отдельные подписи не передаются по цепочке. Проверяющий сопоставляет агрегат с предъявленным набором подписантов и сообщений. При предпосылках проекта удаление уже подписавшего посредника должно сделать такую проверку неуспешной, даже если он ничего не поменял. Речь о заявленном свойстве предлагаемого механизма, не об испытании существующего сервиса.

«Одна подпись» не означает постоянного размера всего сообщения. Токены идентичности, входные данные подписей и дайджесты растут вместе с числом переходов. Всем участникам требуется совместимая схема агрегирования. Текст отмечает, что ML-DSA не агрегируется, а возврат к отдельным подписям вновь оставляет возможность удалить неизменивший запрос узел. Один некорректный вклад проваливает проверку целиком, не указывая немедленно виновника. Сама линия изменений не удостоверяет последовательность нескольких подряд идущих узлов, передавших сообщение без правок. Новые имена полей пока лишь запрошены для регистрации IANA.

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

Источники