Support RFC 9421 HTTP Message Signatures for incoming inbox POSTs

[dahlia]

Summary

Incoming ActivityPub inbox verification currently appears to handle legacy draft-cavage style HTTP Signatures, but not RFC 9421 (Signature-Input + structured Signature).

This causes valid modern senders to be marked as invalidly signed and pushed into unverified fallback processing.

Reproduction context

Using Bonfire (from source) with Hollo/Fedify sender:

• Sender posts to inbox with RFC 9421 style headers.
• HTTPSignatures.extract_signature/1 parses a malformed map for this format (e.g. only "headers" => ["date"], "sig1" => ":...:").
• key lookup fails (Could not find any public key to validate).
• valid_signature?: false, then unverified flow is used.

Representative logs from local run:

• parsed signature map: /tmp/bonfire-server.log:92195
• key lookup failure: /tmp/bonfire-server.log:92199
• invalid signature decision: /tmp/bonfire-server.log:92214

Why this matters

• Interoperability with modern implementations that prefer RFC 9421 first.
• Reliance on fetch-based fallback is not equivalent to verified delivery, especially for non-public activities.

Proposal

Add RFC 9421 verification support alongside existing draft-cavage support:

• parse Signature-Input and structured Signature
• map keyid / covered components to actor-key lookup
• validate covered components and body digest semantics used by ActivityPub senders
• preserve backwards compatibility for legacy signature format

Acceptance criteria

• RFC 9421-signed inbox POST validates as valid_signature?: true for compatible senders.
• Existing draft-cavage signed requests keep passing.
• At least one federation integration test for each signature style.

[mayel]

Thanks for opening this! I wasn't aware of RFC 9421 so looking into it now...

[mayel]

@dahlia I'm curious if you've also implemented this? https://helge.codeberg.page/fep/fep/844e/

[dahlia]

@mayel Oh, we hadn't been aware of that! Does Bonfire implement FEP-844e?

[mayel]

Adding support for it now :)

[mayel]

Have now implemented both RFC 9421 incoming verification and signatures on outgoing requests! @dahlia since you have a bonfire dev environment set up, would you be able to check if/how this interoperates with Fedify in both directions? 🙏

The only thing I haven't implemented is outgoing double-knocking, preferring to try discovering what signature method a server supports using several approaches, incl. FEP-844e (+ trying other methods to find a service actor if none is declared as generator), HTTP headers, and nodeinfo (with fallback to mapping certain server apps/versions as supporting the RFC, but would prefer avoiding that if there's a better way...)

[dahlia]

Thanks for the quick implementation, @mayel!

One thing to note: Fedify doesn't implement FEP-844e yet, so Bonfire won't be able to discover that Fedify supports RFC 9421 via the generator.implements mechanism. That means for now, Bonfire will likely fall back to draft-cavage when sending to Fedify instances—so testing the Bonfire → Fedify direction with RFC 9421 isn't quite possible yet.

In the meantime, I'll start with testing the Fedify → Bonfire direction (RFC 9421 outgoing from Fedify, incoming to Bonfire) and report back with the results.

[mayel]

Cool :) It seems like you don't include an Accept-Signature header (RFC 9421 §5.1) either based on my testing? That's why I also included the nodeinfo fallback, so should be testable thanks to that as well.