support rfc9421: HTTP Message Signatures

[GlenDC]

• RFC: https://datatracker.ietf.org/doc/html/rfc9421
• useful take by Daniel Stenberg: https://daniel.haxx.se/blog/2026/07/27/http-message-signatures-with-curl/

TLDR: http requests and responses can be signed to let the other side of the communication verify that something is unaltered. This is something we also want to support for clients and servers. However it is also important for MITM proxies as those might modify a part that would change the signature. As such we will also need a layer for both directions to ensure we update an existing signatures to the new state prior to sending it through.

For the crypto primitives you can ideally make use of rama-crypto. If something is missing let us known or make it part of the PR if contained enough.

For this issue @soundofspace and myself (@GlenDC ) can both mentor.

No high priority for now as I haven't received any bug reports about it. That said once you start on it do as per usual try to finish it within a matter of days or weeks, rather than months. We do not like things to get dragged on forever, it's not fun for any party involved.

[Shaurya2k06]

Spent some time understanding the issue mentioned, I think I'd like to give it a shot. This is quite a big task so I've scoped it into a set of PRs:
PR1- Headers + sign/verify (ed25519, hmac-sha256)
PR2- Content-Digest + MITM re-sign

How are we deciding to scope it out?
cc @GlenDC @soundofspace

[GlenDC]

Can you ellaborate more on how you see those 2 PRs.

Specifically not sure why that content-digest is linked to MITM re-sign.
Would that not make more sense to be part of PR#1? Perhaps even splitting that first PR in 2 if you see it 2 big.

How are we deciding to scope it out?

The RFC is the scope, haven't read it in detail though so if you see something too big in there do let me know.
Other than that is important we support it from a client, server and (MITM) proxy POV.

Splitting it up in multiple PRs is fine for me. We can review fairly quickly. Just need to ensure you are up for the task, can explain in more detail what you plan to do for the PRs and have the available time and energy to finish what you start.

[Shaurya2k06]

I've split the RFC 9421 (HTTP Message Signatures) implementation into three stacked PRs to keep review scope manageable:

#1083 — Signature primitives (headers + signature base) Foundation layer, no signing/verification logic yet. Focuses on getting canonicalization exactly right before anything depends on it:

Minimal Structured Fields (RFC 9651) subset: dictionaries, lists, items, parameters
Typed Signature / Signature-Input headers
Component extraction and signature-base assembly (method, authority, target-uri, query-param, field params ;sf / ;bs / ;key / ;req)
Fail-closed canonicalization: typed ;sf (no dict/list/item guessing), encoded query-param name matching, normalized @target-uri, correct Display String percent-encoding, ;key boolean-true as ?1

#1084 — Sign/verify layers + Content-Digest :
Makes the primitives actually usable for signing and verifying messages:

Typed Content-Digest (RFC 9530, sha-256/sha-512)
rama-crypto adapters for ed25519, hmac-sha256, ecdsa-p256-sha256, rsa-v1_5-sha256, rsa-pss-sha512 including JWK kty/curve validation so a key's claimed algorithm can't disagree with its actual type
Request/response sign and verify layers behind the message-signature feature
Related-request context for response ;req, a required-components policy, and wire-order preservation for verify

#1085 Proxy/intermediary layers:
Adds the intermediary use case where a proxy signs on top of an already-signed message:
Appends a new label without overwriting existing Signature/Signature-Input entries
Rejects malformed existing signature headers instead of silently replacing them
Response signing with related-request context for ;req

Each PR includes the focused cargo test / clippy / fmt runs for its slice.
Happy to adjust scope or ordering if you'd prefer it split differently though
cc @GlenDC @soundofspace.

[GlenDC]

Your PRs were closed as-is, for vialotation of our contributor terms of agreement.
See for more information: https://github.com/plabayo/rama/blob/main/CONTRIBUTING.md#contribution-terms

This is your only and final warning (posted also in all your 3 PRs). Next time it's a ban.

We are happy to have you in our community @Shaurya2k06 , and embrace you with pleasure. However, the goal is not for contributors to hand over the work to an AI agent with little to no direct involvement from you. Such work is many times more work to review than to do it ourselves, without the otherwise accepted tradeoff that you learn from it. We do not mind putting in the work to mentor humans, but not AI agents.

Do not get me wrong, we do not care what IDE, keyboard, computer or tool you use. But you have to own the work in all the meanings of that word. Pushing 3 PRs that are clearly generated agentically is not the way. Please report back in this issue whether you want to do it yourself, with care and respect. Or if you rather have someone else pick up the work.