Кратко

  • HTTP message signature защищает упорядоченный набор полей, производных компонентов и параметров. Метод, authority, target, credential или content вне списка можно изменить, не нарушив криптографическую проверку.
  • Verifier сам выбирает нужную подпись и допустимый ключ, проверяет время, replay, digest, principal и разрешение на конкретный ресурс и действие. keyid, nonce и tag только передают данные для этой политики.
  • Когда proxy проверяет исходную подпись, меняет сообщение и подписывает внутреннюю форму, возникает новое свидетельство. Подпись proxy не превращает добавленные им поля в заявление клиента.

Правильные байты оказались у неправильной операции

Сервис получает подписанный JSON. Ключ активен, алгоритм разрешён, created попадает в окно, а Content-Digest совпадает. Система показывает зелёный результат.

В Signature-Input, однако, перечислены только date и content-digest. Нет @method, @authority, @target-uri, контекста авторизации и одноразового значения. Владелец ключа мог одобрить это тело, но доказательство не говорит, для какого host, path, method, account и количества применений оно предназначалось.

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

Криптография выполнила обещание. Организация ошибочно расширила это обещание до права отдавать команду.

RFC 9421 строит общий смысл, а не копию провода

HTTP проходит через посредников. Они объединяют строки полей, переводят версии протокола, добавляют routing context и меняют content encoding. Подпись необработанных bytes ломалась бы от допустимой трансформации.

RFC 9421 задаёт детерминированную signature base. Signer выбирает HTTP fields и derived components: @method, @authority, @target-uri, @status. Порядок записан в Signature-Input. Последний @signature-params связывает с доказательством сам список и параметры created, expires, keyid, nonce, tag.

Получатель строит базу из реально полученного сообщения. Успех означает семантическую эквивалентность только по охваченному подмножеству. Он не распространяется на соседние поля и весь бизнес-контекст.

Две valid signatures с разными списками говорят о разных объектах, даже если созданы одним key.

Coverage profile является рабочей политикой

У разных операций разные смысловые границы. Для чтения могут требоваться method, authority и target. Изменение сетевой конфигурации добавляет body digest, identity, resource version, idempotency key и challenge. Подписанная квитанция связывает status и исходный request.

Приложение обязано сравнить наблюдаемый список с профилем именно этого method и route. Одно наличие Signature ничего не говорит о достаточности.

Без @method подтверждение чтения можно приложить к изменению. Без authority и target сообщение переходит между сервисами или tenants. Если authorization field не защищён, к подлинным компонентам присоединяется другая identity claim.

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

Здесь работает принцип Heng Lu Minimum Initial Specification: общий слой строго задаёт локально проверяемые construction и verification, а выбор обязательных компонентов, ключей и последствий остаётся у running participants.

Тело входит в доказательство через digest

RFC 9421 не помещает произвольный body прямо в signature base. RFC 9530 даёт Content-Digest. Нужно вычислить поле, охватить его подписью и после получения заново вычислить digest из фактического content.

Если digest не подписан, его меняют вместе с телом. Если подписан, но не пересчитан, значение оставляют прежним, а тело заменяют. Подпись доказывает сохранность утверждения о digest; повторный расчёт связывает утверждение с предметом.

Важны Content-Type и Content-Encoding. Те же bytes могут получить другой parser или другую границу representation. Криптографическая точность не решает вопрос, что именно означают bytes.

Digest в trailer приходит поздно и может исчезнуть у intermediary. Если application действует до trailer, эффект опережает доказательство. Для необратимой команды требуется buffer или transaction boundary.

Существующая статья BTW о Digest Fields исследует, какие bytes названы. Эта статья исследует authority, связывающую digest с методом, target и signer. Темы соседние, но не одинаковые.

keyid указывает, но не удостоверяет

Значение keyid сообщает сам signer. RFC 9421 оставляет key discovery, алгоритмы и identity binding приложению.

Если verifier принимает любой public key из запроса, атакующий подписывает свою команду своим ключом и успешно проходит. Математика устанавливает possession. Local trust policy должна установить principal, role, active interval и operation scope.

В доказательстве сохраняют реально разрешённую key version, источник и версию trust policy, algorithm, активацию, отзыв и разрешённые действия. Строка keyid без этого контекста после rotation неоднозначна.

Dual signatures полезны при миграции, если известны начало, сравнение и retirement. Бессрочная совместимость только расширяет поверхность старого authority.

IANA registration даёт совместимое имя. Она не утверждает, что algorithm подходит для удаления данных, денег или инфраструктуры.

Свежее сообщение может быть повторным

created задаёт время создания, expires — границу, до которой signer готов отвечать за подпись. Verifier выбирает age и clock tolerance. Математически корректное доказательство может быть слишком старым для риска.

Но короткое окно не создаёт однократность. В течение него один запрос выполняется несколько раз.

nonce несёт одноразовое значение, однако его нужно атомарно потреблять. Два региона могут одновременно увидеть «не использован» и сделать два commits. Anti-replay — распределённое состояние с областью и сроком хранения.

tag помогает найти подпись нужного профиля. Публичное значение копируется и само ничего не разрешает.

Повторная подпись proxy открывает другую custody boundary

RFC 9110 считает intermediaries обычной частью HTTP. Gateway может проверить client signature, удалить privacy field, переписать internal target и подписать результат.

Новая подпись сообщает, что утверждает gateway. Она не доказывает, что client одобрил добавленные позже поля. Origin определяет полномочия proxy: только переносить результат проверки или действовать как внутренний principal.

Последний Boolean стирает происхождение. Нужны external context, выбранная client signature, применённый profile, transformation и internal context с proxy signature.

При переходе HTTP/1.1–HTTP/2 authority выражается Host или :authority. Derived component @authority хранит смысл. Wire-specific field может сломаться при законном переводе либо привести verification и authorization к разным authorities.

Несколько подписей требуют выбора

Client, gateway и approver могут подписать одно сообщение. При algorithm migration появляются старая и новая подписи. Все могут быть valid, но ни одна не обязана соответствовать текущей операции.

Первый успешный результат может оказаться logging signature вместо execution mandate. Label и tag находят кандидата, после чего проверяются role, key, components и context.

В response параметр req покрывает компоненты связанного request. Verifier должен иметь точный request context. Две отдельно сохранённые подписанные записи не доказывают причинную связь.

TLS и authorization остаются отдельными системами

TLS 1.3 защищает канал и даёт confidentiality. HTTP Message Signatures сохраняет выбранную семантику через connections и некоторых intermediaries. Она не шифрует и не отменяет TLS.

HTTP authentication предъявляет credentials, но application сравнивает principal, resource, action и state. Подписанный response не получает автоматическое право на cache; это регулирует RFC 9111.

По Heng Lu Reality Layers signature base — coordination artifact, verification — cryptographic fact, key mapping — identity claim, authorization — local decision, а commit и downstream effect — operational reality. Ранний слой не получает власть позднего только из-за ясности своего результата.

Источники и пределы

Источники определяют формат и security boundaries. Они не доказывают нынешнее deployment, поведение vendor, человеческую личность, юридическую волю, non-repudiation или бизнес-правильность.