Verifizierer für HTTP Message Signatures

A signature over selected parts of a message

HTTP Message Signatures (RFC 9421, February 2024) sign an HTTP request or response that is still moving: proxies may add headers, reorder them or change the connection, and the signature has to survive that. So the signer does not sign the message as bytes. It picks covered components — header fields such as content-type, and derived components such as @method, @authority, @path, @query or @status — and serialises their values into a text called the signature base (§2.5). The last line, @signature-params, repeats the list of components and the signature parameters, so the list itself is signed. Two fields then travel in the message: Signature-Input with the components and parameters, and Signature with the bytes, both Structured Fields dictionaries keyed by a label such as sig1.

A verifier has to rebuild exactly the same base from the message it received. That is where almost every interoperability failure comes from: a header combined differently when it occurs twice, @authority with or without a default port, a query string with different percent-encoding, @target-uri built with http behind a TLS-terminating proxy. The verifier shows the base it rebuilt for every signature, line by line, so you can put it next to the one your library produces and see the first differing byte.

What the verifier checks

For every signature label:

• The components. Each must exist in the message (or, with the ;req parameter, in the request a response answers — paste it into The request this response answers). Parameters such as ;sf (re-serialise a Structured Field), ;bs (byte sequence per value), ;key (one dictionary member) and ;tr (trailer) are applied as §2.1 defines them.
• The parameters. created must not lie in the future and expires not in the past at the check time; alg, when present, must match the key; keyid and tag are shown.
• The key. It is matched by label, by keyid, by a JWK's kid, or used for every signature when you give only one. Keys can be JWKs, PEM public keys, certificates or raw Ed25519 keys; shared HMAC secrets go into rows of their own.
• The signature, with every algorithm of the HTTP Signature Algorithms registry: ed25519, ecdsa-p256-sha256, ecdsa-p384-sha384, rsa-pss-sha512, rsa-v1_5-sha256 and hmac-sha256. Without an alg parameter, the algorithms the key allows are tried, and the report says the algorithm was inferred.
• Content-Digest and Repr-Digest (RFC 9530) against the body, since a signature protects the body only through a covered digest field.

Then it explains what the signature does not protect, which is the part most often misunderstood. A request signature without @method stays valid for another method; without @authority it can be replayed against another host; without a path component it is valid for every resource; a body without a covered digest can be changed at will; a signature without expires or nonce can be replayed until the verifier's own policy rejects it. RFC 9421 §7 describes each of these; the verifier names the ones that apply to your message.

Examples

The examples are the test vectors of RFC 9421 Appendix B: the minimal, selective and full-coverage request signatures of B.2.1–B.2.3 with RSA-PSS, the ECDSA-signed response of B.2.4, HMAC-SHA256 with the published test secret in B.2.5, Ed25519 in B.2.6, the TLS-terminating proxy that signs the client certificate in B.3, and a response that covers request components from §2.4. They were created in 2021, so the example sets the check time accordingly.

Bots and AI agents sign their requests with exactly this mechanism, plus a key directory: the Web Bot Auth checker adds the profile checks and the directory lookup. To bind a token to a client key with a lighter, JWT-based proof, see the DPoP proof inspector. The standard in depth: HTTP Message Signatures (RFC 9421) for APIs and bots.