Double-knock strategy for HTTP Signature
In the HTTP Signature Report we suggest a double-knock strategy for deploying RFC 9421. Basically, try RFC 9421 first, and if you get an error, downshift to draft-cavage-12 and try again.
I just realised, in testing with Pixelfed, that this doesn't work if the remote server doesn't check signatures in the Web routes. Pixelfed returns a 200 response for POST requests signed with RFC 9421, but its backend workers reject the input because Pixelfed doesn't understand RFC 9421. So, it silently swallows activities with RFC 9421 signatures.
I think there are a few other strategies to try. One is tit-for-tat: if a host sends you POST requests signed using RFC 9421, you should be able to send them back with RFC 9421. Another is checking for the Accept-Signature header. Finally, you can use an allowlist/denylist based on nodeinfo, the Server header, or the User-Agent header.
Has anyone else figured out a good way around this?
6 replies
I added a ticket here: https://github.com/swicg/activitypub-http-signature/issues/65
@[email protected] I wonder if you've had this problem and how you worked around it.
@evan I do know that @[email protected] currently only implements RFC 9421 in one direction only.
So his input may be relevant here... the assumption that if you see 9421 in action, you can assume 9421 support may not be as broadly true.
@julian @evan @technical-discussion I proposed FEP-844e as an alternative to double-knocking, it should work well for POST requests because normally you fetch an actor before sending activities to its inbox. Several early adopters of RFC 9421 already implemented this FEP (including WordPress).
> @[email protected] said: > > it should work well for POST requests because normally you fetch an actor before sending activities to its inbox.
Aside: we should? I cache the inbox locally so I don't have to... I believe I read somewhere that bonfire (cc @[email protected]) also caches whether a recipient supports 9421
@julian @mayel @technical-discussion I mean it should be fetched to learn about its inbox URI. No need to re-fetch the actor if it is already cached.