2026-09-22 · 8 min read
- http
- signatures
- security
HTTP message signatures allow a sender to sign selected fields and derived request or response components. The signature input identifies what is covered and carries parameters, while the signature value contains the cryptographic result under a label.
Unlike signing a stored JSON object, the design must account for HTTP parsing, repeated fields, request targets, intermediaries, and the exact point where components are derived. Transport security remains necessary because signatures do not automatically provide confidentiality.
Define a signature profile
Specify the message direction, required covered components, allowed algorithms, key discovery and trust, signature parameters, freshness window, replay control, and failure response. Profiles should cover enough context to prevent a valid message from being moved to another operation.
- Include the method and target identity where appropriate.
- Cover content integrity metadata when a body matters.
- Allowlist algorithms and key types.
- Reject missing required components before verification.
Construct the signature base exactly
Use a maintained implementation of HTTP Structured Fields and the message-signature specification. Preserve the declared component order, component parameters, normalized identifiers, derived-component rules, and final signature-parameters line.
Do not invent generic header canonicalization, combine fields by guesswork, or reconstruct a URL from untrusted forwarding fields. Capture escaped debug representations or digests of public test bases when raw production values are sensitive.
Place trust boundaries around proxies
Choose whether signing and verification happen outside, inside, or at a gateway, then inventory every transformation between those points. Scheme, authority, path, query, field values, content coding, and digest metadata can change across an intermediary.
Validate key identity, algorithm, created and expiry times, nonce or request identity, and replay state in addition to the signature bytes. Key identifiers select candidates; they do not establish trust by themselves.
Use interoperable conformance vectors
Use Flashman's URL tool for harmless targets, Base64 and hash tools for published bytes, diff for signature-base lines, and timestamp converter for freshness windows. Use reviewed cryptographic libraries with protected key storage in production.
Test repeated and empty fields, query parameters, non-ASCII targets, proxy rewriting, request and response signatures, content digests, several labeled signatures, unsupported algorithms, malformed structured fields, freshness boundaries, nonce replay, key rotation, failure telemetry, and independent implementations.