TLS protects an HTTP exchange while traffic moves across a TLS connection, but some application designs need a cryptographic assertion attached to the HTTP message itself. A gateway may terminate TLS before forwarding a request, a service may need to authenticate selected request metadata, or a message may cross several HTTP hops where transport protection and application trust are separate concerns.
HTTP Message Signatures, specified in RFC 9421, address that boundary. A signer chooses HTTP message components, constructs a defined signature base, signs it, and sends metadata that tells a verifier which components and parameters were covered. The mechanism is selective by design: a signature does not automatically cover every field or every property of the message.
The covered-component list defines the signed scope
A signature begins with an explicit set of covered components. These can include HTTP fields and derived components such as @method, @authority, @path, or @status, subject to the rules in RFC 9421.
That list is security-critical. If authorization depends on the request method and target path, signing only an application field leaves those routing properties outside the cryptographic assertion. If a verifier makes a decision from a component that the signature does not cover, the signature cannot authenticate that input.
The design therefore separates cryptographic validity from application policy. A signature can be mathematically valid while still being insufficient for a particular authorization decision. Verifiers need a policy that states which components must be covered for each operation.
Signature-Input carries the signing metadata
RFC 9421 uses the Signature-Input field to describe a labeled signature. Its value identifies the covered components and can carry signature parameters such as created, expires, nonce, alg, and keyid.
The Signature field carries the corresponding signature bytes. Labels connect entries in Signature-Input with entries in Signature, allowing a message to carry more than one signature when an application requires separate assertions.
Parameters are not interchangeable with external policy. A keyid can help a verifier select key material, but the identifier alone does not establish that the key is trusted for the requested action. Likewise, an alg parameter describes algorithm information in the signature metadata; acceptance still depends on the verifier’s cryptographic and application policy.
Time-related parameters also need local checks. A verifier that relies on created or expires has to compare them against an acceptable clock and policy window. A signed timestamp does not by itself prevent replay.
Canonical serialization creates the signature base
HTTP permits representations that can be equivalent at the protocol level while differing in raw bytes. Signing arbitrary wire bytes would make signatures fragile across compliant processing. HTTP Message Signatures instead define rules for deriving covered component values and serializing them into a signature base.
The signer and verifier independently build that base from the selected components and signature parameters. Verification succeeds only when the verifier reconstructs the material expected by the cryptographic signature.
This does not mean intermediaries may freely alter signed semantics. A proxy transformation that changes a covered component can make verification fail. Components that are expected to change across hops need careful placement in the signed scope, or signatures need to be created and verified at boundaries where those values are stable.
Canonicalization is therefore part of the security protocol, not a formatting convenience. Implementations should use the RFC-defined processing model rather than inventing ad hoc string concatenation rules.
Content integrity requires the right components
A message signature can authenticate fields that describe content, but it does not implicitly hash an HTTP message body merely because the request is signed. Applications that need body integrity commonly combine message signatures with content-digest fields defined for HTTP and include the relevant digest field in the covered components.
That composition matters. If a digest is present but not covered by the signature, an attacker who can alter both the body and the unprotected digest may preserve their consistency without preserving the signer’s assertion. The verifier’s policy needs to bind the content digest into the signature when body integrity is required.
The same principle applies to routing and authorization metadata. Security properties come from the exact set of authenticated inputs, not from the presence of a Signature field alone.
Replay control remains an application responsibility
A valid signature proves that the signed material matches a signature produced with the relevant signing key under the selected algorithm. It does not prove that the message is fresh or that the same signed request has not been presented before.
RFC 9421 provides parameters that can support replay defenses, including timestamps and a nonce, but an application has to define and enforce the corresponding policy. A nonce has value only when the verifier can decide whether it is acceptable and, where required, whether it has already been used. Expiration limits can narrow a replay window but do not automatically provide single-use semantics.
Key authorization also remains external to signature verification. A service must map a verified key to an identity, role, tenant, capability, or other authorization context before granting an operation.
Transport security and message signatures cover different boundaries
HTTP Message Signatures do not replace TLS. TLS can provide confidentiality, peer authentication, and integrity for traffic on a connection. Message signatures provide a cryptographic assertion over selected HTTP components that can be evaluated at the application layer.
Using both can be appropriate when the trust boundaries differ. TLS can protect each network leg while a message signature carries an application assertion across a gateway or service chain. The signature’s value depends on disciplined component selection, key management, replay policy, and authorization checks at the verifier.
The useful security property is narrow and explicit: selected HTTP components are bound to a cryptographic signature and its metadata. Everything outside that covered set remains outside that assertion.