Using `Forwarded` header (RFC 7239) for inbox forwarding with HTTP Signatures?

[trwnh]

From Section 4, "So, what's the verdict?"

We'd often like to authenticate objects and activities outside of inbox delivery requests, eg during inbox forwarding, or after they were initially created. HTTP Signatures can't do this.

https://www.rfc-editor.org/rfc/rfc7239#section-4 mentions a Forwarded HTTP header that can be used on HTTP requests to include additional information. Perhaps aspects of the original HTTP signature can be relayed through this header when inbox forwarding takes place? This is something that could be mentioned briefly in the report for a "future directions" type of angle.

[snarfed]

Sorry I missed this! Interesting idea! I'd be curious to hear more. Do you have a concrete sense of how Forwarded could be used to reconstitute and verify the original signature, and if that would provide enough authn to be useful?

[trwnh]

POST /inbox2 HTTP/1.1
Host: host2.example
Signature: ...
Forwarded: Signature="..."; Host=host1.example; ...

In this example, the Signature is the forwarder's signature, to authenticate that they were the actor who forwarded the message. The Forwarded header contains the original signature and any params needed in order to validate the original signature, which authenticates that the activity was indeed initially delivered by someone authorized to act on behalf of the actor of the activity.

[ag-eitilt]

As another example, I know we're still not at hs2019 support yet, much less the final (incompatible) version, but the RFC 9421 which came out of it does provide another example of forwarding a signed message being annotated with the Forwarded header. Their particular use case involves a trusted proxy and leaves the final destination unable to verify the original signature, so it won't work for ActivityPub forwarding.

I do really like the idea of including any headers the relay changed in the Forwarded value, but unfortunately the keys there aren't actually arbitrary headers as much as host=... would suggest otherwise; in the section after the one you linked, RFC 7239 only lists four potential parameters without provision for freeform keys, and while it does allow extension, INIA doesn't show any changes. We could certainly introduce a non-normative extension, but unless we want to go through the whole registration process, it would be effectively ad-hoc. The other difficulty is that Forwarded applies special meaning to both commas (which Cavage and hs2019 use within Signature) and semicolons (which RFC 9421 does in Signature-Inputs), and so far as I'm aware wouldn't treat double-quotes as being anything special, so we'd have to have some other process of escaping them -- and that's particularly relevant since we'd need to include other headers the signature covers alongside it if the relay changed any of them for some reason¹ and those could also include the same problematic characters. I was wrong on this, there is a construct of a quoted string they're using which prevents those characters from being treated specially.

Also, I'm not entirely sure this is the best place to be having this discussion? My impression of this repo/document is that it's more of a survey of existing implementations, rather than being intended for normative changes, even just to the extent of "future directions" (EDIT: at least, ones which the community at large hasn't already decided we're working toward). I'm still very new to the AP dev community, so I don't know where this should be, but there's certainly going to be much fewer eyes here than there would be on SocialHub.

Footnotes

1. In particular, I can see Date being updated to when the relay forwarded the message if it's not sent blindly on, depending on what library it's using to construct the outgoing message. Though admittedly my mental model of the process is still closer to one which would require object signatures for verification rather than being something HTTP signatures would be able to cover. ↩

[trwnh]

Thank you @ag-eitilt -- I was mainly raising it here as a suggestion for a brief mention in "future directions". At the very least, the HTTP Signatures can't do this. bit is not fully correct. HTTP Signatures can't do anything outside the bounds of an HTTP request, but it can be used to handle inbox forwarding provided some mechanism for retaining a signature from the original authority. This can be either the original HTTP Signature, or it can be an LD Signature / Object integrity proof, or it could be sidestepped by fetching from origin if resolvable.