洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Looking for implementations with support! 🔍

As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.

The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:

  • has implemented RFC 9421 (even in a development branch)
  • is currently implementing it
  • has plans to implement it soon

Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into 's main branch.

Any leads or connections would be greatly appreciated! 🙏

Fedify: ActivityPub server framework's avatar
Fedify: ActivityPub server framework

@fedify@hollo.social

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in , complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.

This implementation includes both signature generation and verification, meaning is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other implementations. Once these tests confirm compatibility, we'll proceed with the merge.

As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the . Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.

Currently, we support RSA-PKCS-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.

We look forward to contributing to a more standardized and secure fediverse!

HTTP Message Signatures This API is available since Fedify 1.6.0. RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities. Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them. NOTE Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
ALT text detailsHTTP Message Signatures This API is available since Fedify 1.6.0. RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities. Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them. NOTE Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.
Double-knocking HTTP Signatures This API is available since Fedify 1.6.0. As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet. To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
ALT text detailsDouble-knocking HTTP Signatures This API is available since Fedify 1.6.0. As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet. To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
Sebastian Lasse's avatar
Sebastian Lasse

@sl007@digitalcourage.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee

Hey Hong, yesterday Michiel Leenars of nlnet made me aware of this funded project
feditest.org/
Didn't look into it deep yet but feeling is that this is such a test :)

Gabbo the wafrn guy's avatar
Gabbo the wafrn guy

@gabboman@app.wafrn.net · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

I think I do?

crawlpaw 🎃's avatar
crawlpaw 🎃

@bouncepaw@merveilles.town · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee CC @tedu

silverpill's avatar
silverpill

@silverpill@mitra.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee Is it difficult to implement? I hate RFC 9421 but its adoption seems inevitable now, so I may give it a try

tedu's avatar
tedu

@tedu@honk.tedunangst.com · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee I should be able to receive your replies here. Verification passed at least some of the RFC tests.

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

Okay, I've just deployed a bleeding edge , which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)