Summary

  • An HTTP message signature proves semantic equivalence only for the ordered fields, derived components and signature parameters placed in its signature base. A valid result says nothing about a decisive method, target, authority, credential or body that the profile left outside that set.
  • The verifier, not the Signature field, owns the trust decision. It must select an appropriate signature, resolve an acceptable key and algorithm, enforce time and replay policy, recompute any signed content digest, map the signer to a principal and authorize the requested effect.
  • Proxies can validate, transform and add their own signatures, but every such step creates a custody boundary. Preserving only the last green result destroys the distinction between what the client signed, what the gateway observed and what the application eventually executed.

A correct proof over the wrong command

A service receives a POST that appears unusually well protected. The Signature value verifies. Its created time falls inside the accepted window. The declared Content-Digest also matches the JSON body. The security dashboard turns green.

The signature base, however, covers only date and content-digest. It does not cover @method, @authority, @target-uri, the authorization field or an application nonce. The signed body may be evidence that a key holder approved those bytes at a certain time. It is not evidence that the holder approved this method at this host and path, under this account, for one use only.

An intermediary can present the same protected body to a second endpoint that interprets it as an irreversible instruction. A captured request can be replayed within the time window. A routing layer can change the external authority to an internal service name. Every cryptographic calculation can remain correct while the operational command becomes wrong.

That is not a failure of digital signatures. It is a failure to say what the signature was allowed to mean.

RFC 9421 signs a reconstructed semantic object

HTTP cannot assume that the bytes emitted by one hop reach another hop unchanged. Proxies combine or separate field lines, translate protocol versions, add forwarding information, change content coding and reconstruct targets. Signing the raw wire image would make normal intermediation look like tampering.

RFC 9421 therefore defines a signature over a deterministic string assembled from selected message components. A component may be an HTTP field or a derived value such as @method, @authority, @target-uri or @status. Their identifiers and order appear in Signature-Input. The final @signature-params line binds that component list and parameters such as created, expires, keyid, nonce and tag into the same proof.

The verifier reconstructs the base from the message it actually received and applies the chosen cryptographic verification operation. If that succeeds, the standard's promise is precise: the received message is semantically equivalent to the signed message with respect to the covered subset.

The final phrase is the boundary. A signature over two components is not a weaker mathematical version of a signature over ten. It is a proof about a different object.

Coverage is the real policy surface

Applications decide which message properties control an operation. A read-only request may need method, authority and target binding. A money movement or infrastructure change may also need content type, content digest, account credential, idempotency key and an application challenge. A response used as a receipt may need status, digest and selected request components.

RFC 9421 supplies identifiers and canonicalization. It does not declare one universal coverage profile, because HTTP applications disagree about which changes preserve meaning. That flexibility is essential for intermediaries, but it moves authority into configuration.

A verifier must compare the signature's declared coverage with a profile for the exact operation. Merely finding Signature and Signature-Input is not enough. A DELETE signature that omits @method can be transplanted onto a different method. A tenant operation that omits @authority or @target-uri can cross a routing boundary. A request whose authorization credential is unsigned can carry a valid proof beside a substituted identity claim.

The safest rule is not “sign every field.” Some fields, including Via and Forwarded, are expected to change. Signing them can make a legitimate proxy path impossible. The discipline is to sign every component whose change would alter the authorization or effect, while explicitly documenting the components that a trusted intermediary may transform.

A body enters through a digest

RFC 9421 does not place arbitrary message content directly in the signature base. Content is normally bound through RFC 9530: compute Content-Digest, include that field among the covered components, verify the message signature and recompute the digest over the received content.

All four steps matter. If Content-Digest is present but unsigned, an attacker can replace both body and digest. If it is signed but never recomputed, an attacker can leave the protected digest value in place and replace the body. If relevant Content-Type or Content-Encoding metadata is left outside the profile, identical bytes can reach a different parser or the digest can be evaluated over the wrong representation boundary.

Trailer delivery adds another decision. Intermediaries are allowed to drop trailers, and an application that acts on a streaming body before its trailer digest arrives has accepted content before validation. That may be reasonable for reversible buffering and unacceptable for an irreversible command.

The earlier BTW article on Digest Fields explains which bytes a digest names. Message signatures solve a different problem: who protected the digest statement, alongside which control components, in which signature context. Neither mechanism absorbs the other.

A key name is not a trust decision

The keyid parameter tells a verifier which key the signer wants it to consider. It is not a certificate issued by the field itself. RFC 9421 deliberately leaves key discovery, acceptable algorithms and the relationship between a key and a signer to the application.

This prevents a syntax standard from becoming a global identity authority. It also means that a permissive resolver can defeat perfect cryptography. If a service accepts any public key supplied by a request, an attacker can sign the attacker's own message and pass verification. The mathematics establishes possession of the corresponding private key; local trust policy must establish whether that key belongs to an allowed principal, role and epoch.

Key evidence therefore needs more than a string. Record the resolved key version, trust-source version, algorithm policy, activation and retirement interval, mapped principal and permitted operation class. During rotation, old and new signatures may coexist, but the verifier must know whether that is an announced migration, an emergency rollback or an unexpected widening of authority.

An entry in an IANA registry makes an identifier interoperable. It does not approve the algorithm for every risk class. A key in a company directory proves only what that directory is authorized and able to assert.

Time parameters do not enforce themselves

created records when the signature was made. expires expresses when the signer is no longer willing to vouch for it. RFC 9421 leaves the acceptable age, clock tolerance and processing rule to the application. A signature can be mathematically valid and operationally too old.

Time bounds also do not make a request single-use. A five-minute window permits five minutes of replay unless the message and verifier state distinguish the authorized event. Covering a unique business identifier helps, but only if the application enforces its uniqueness atomically.

The nonce parameter provides a place for a per-message value. The verifier must issue or recognize the challenge, store used state and reject a repeated value. In a multi-region system, two sites that check before either commits can both accept the same nonce. Anti-replay is a distributed state transition, not a decorative signature parameter.

The tag parameter can help choose signatures intended for one application profile. Its value is public, so an attacker can copy it. A tag narrows a search; it does not confer authority.

Intermediaries create a chain of custody

RFC 9110 treats HTTP as an intermediation protocol. A reverse proxy may terminate a client connection, normalize a target, add internal routing fields or change content coding before passing a message to an origin service. RFC 9421 allows multiple signatures precisely because one signature cannot always survive or describe every hop.

A gateway can verify the client signature, remove privacy-sensitive information, transform the message and add its own signature. Downstream, the gateway signature proves what the gateway now asserts. It does not retroactively make the transformed fields part of the client's original statement.

The evidence record should retain both realities: which client signature was checked against which external request context, what transformation occurred, and which proxy signature protected the internal form. If the origin stores only “signature valid: gateway,” it may be unable to show whether the client ever signed the method, public authority or target that drove authorization.

HTTP version translation demands the same care. Authority can appear as Host in HTTP/1.1 and as :authority in HTTP/2. The derived @authority component is designed to represent the semantic value across versions. Signing only one wire-specific field can fail after a legitimate translation or tempt a verifier to reconstruct the wrong context.

Several valid signatures can disagree about relevance

A message can carry signatures from a client, a gateway and a business approver. It can also carry two algorithms during migration. Each label may cover a different component set.

This is useful only if the recipient has a selection rule. A naive service that accepts the first signature that verifies can mistake a logging signature for a payment authorization or a proxy receipt for an end-client instruction. The tag, signer identity and label help identify candidates, but the verifier still has to require the correct profile and key role.

Response signing introduces another context boundary. The req parameter lets a response signature cover components of its associated request. A verifier must possess that exact request context. A valid receipt that is detached from its initiating request cannot prove which command produced it merely because both messages contain signatures.

Signatures do not replace TLS or application judgment

TLS 1.3 protects a transport channel, negotiates keys and can authenticate the server and, where configured, a client. HTTP Message Signatures protect selected message semantics in a way that can survive beyond one connection or across intermediaries. The mechanisms complement each other.

Message signatures provide no confidentiality. TLS does not automatically preserve end-to-end message provenance across a terminating proxy. Neither mechanism decides whether a principal may execute the current operation. HTTP authentication can present credentials, yet application authorization must still compare identity, resource, action and state.

Caching is another independent decision. A signed response is not automatically reusable for another request or another user. RFC 9111 governs cache behavior; the signature can be evidence about selected response components, not a universal cache grant.

This separation follows Heng Lu's reality-layer discipline. The signature base is a deterministic coordination artifact. Cryptographic verification is a running result. Key mapping is an identity claim. Authorization is a local institutional and software decision. The committed operation and its downstream effects are operational reality. Clarity comes from refusing to let an earlier layer impersonate a later one.

Sources and evidentiary limits

This analysis uses the following public sources:

The standards define formats, algorithms and security considerations. They do not establish present deployment share, the behavior of a named product, a global key-discovery authority or a universal authorization profile. No signature proves legal intent, human identity, non-repudiation or business correctness without additional evidence.