#rfc9421 — Public Fediverse posts

I think the #RFC9421 HTTP Signature algorithm should be explicitly included in #Mastodon's requests.

Feedback welcome - especially those explaining politely why I'm a wrong about this.

https://github.com/mastodon/mastodon/issues/29905#issuecomment-5440336919

@interledger @evan If anyone would like this bounty, then you can fork @peertube/http-signature into its own NPM namespace using my forked branch, which provides a backward-compatible RFC 9421 implementation that would make it easier for software to handle both cavage-12 draft and RFC 9421. You will probably need to maintain it for a couple of years so that the JavaScript/TypeScript ActivityPub community can coalesce and focus on a stable replacement (probably fedify or misskey).

@[email protected]

Double-Knock... i can just guess, that some considering RFC 9421 signatures as the preferred variant, so that this is suggested to try first.

It might be possible, that i start to do a double-knocking at the beginning with Draft Cavage 12 first.

Regarding "to send both signatures at once": Both signature types are using a "Signature" header. So it doesn't look like you can send both signature types at once.

Btw.: Was your post shortened on #Mastodon? (I saw it first on norden.social).

#Fediverse #ActivityPub #Signature #HTTP #RFC9421 #DraftCavage12

@evan #RFC9421

The Interledger Foundation @Interledger has an open funding call for libraries implementing #RFC9421 (HTTP Signature). This is crucial infrastructure for #ActivityPub. Go get that money!

https://interledger.org/grant/open-payments-sdk

When last I left off, I made a pull request to peertube/http-signature library try to help the JavaScript ecosystem reach RFC 9421 parity while being backwards-compatible with cavage-12 draft implementations. There has not been any traction on this yet. Maybe because PeerTube has abandoned its own use of the library.

So our current ecosystem state is the following:

• PeerTube uses misskey-dev/node-http-message-signatures library and owns the defacto unmaintained peertube/http-signature library.
• Misskey and the rest of the ‘keyverse use peertube/http-signature library and Misskey owns the defacto...

@gabboman I decided to hack on this the past few nights, and came up with an experimental, backwards-compatible implementation that I created a draft pull request for @peertube/http-signature. I tried to follow the library’s coding style of the original as much as possible.

The idea of backwards-compatibility is that you can drop this into an existing application and nothing will break. There are deprecation messages that may surface in logs to guide changing from using the function exports to the cavage12Draft export (and the rfc9421 export).

I think the next step for anyone would be:

• manual...

RE: https://mastodon.social/@bagder/116359048796181736

This feature, once acceptable for merging, will make it easier to use curl with OpenPayments.dev and other APIs using GNAP (RFC 9635 Grant Negotiation and Authorization Protocol, the successor to OAuth 2).

#RFC9421 #RFC9635 #GNAP #OpenPayments #API

Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?

The last time I checked, Lemmy, GoToSocial, Friendica, and the ‘keys to name a few did not handle it. Mastodon didn’t if you included requiring ed25519. But I haven’t checked the code bases or my logs in a month or two, @julian. At that time there wasn’t much progress on peertube/http-signatures or superseriousbusiness/httpsig.

I should probably check again...

RE: https://mastodon.social/@bagder/116359048796181736

Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.

On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.

Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?

#ActivityPub #FediDev #RFC9421

Oh, nice! Congrats to mastodon.social for turning on RFC 9421 signature verification. 🎉

Rereading RFC 9421 HTTP Message Signatures again I noticed that I had missed some specifics to case-sensitivity with regard to covered component values.

• @method value is case-sensitive so the value should be as-is.
• @authority value is normalized to lowercase and the default port is omitted.
• @scheme value MUST be normalized to lowercase.
• Other values are not mentioned specifically so should be as-is based on the HTTP specification including @request-target, @target-uri, @path, and @query. And anything with query parameters could have percent-octet encoded values.

I have been wrongly transforming most values because of muscle memory of cavage-12 draft signature.

When double-knocking for RFC 9421, Lemmy will respond with a 400 Bad Request, so I need to check that as well as a 401 in order to figure out if I should send a follow-up cavage-12 request.

In other news, I still have not debugged why only POST requests are not valid on Mastodon for RFC 9421. There is something unique about comparing the signatures when only content-digest is included, but it is not the digest itself because otherwise Mastodon would raise a validation error earlier. At the moment, only one Mastodon instance I federate with is accepting those requests anyway. Hopefully the error messages aren't too bad.

@obenland I didn't realize that either, and it makes FEP-844e less attractive. However, capability discovery might still be preferable to double-knocking because RFC-9421 is not the last upgrade. Some applications are already starting to use EdDSA signatures, and that requires triple knocking. In the future we will need to switch to post-quantum cryptography and so on. The number of knocks always increases, but capability discovery requires a constant number of requests.

#rfc9421

@silverpill @activitypub.blog I think the main motivation for me to add it was to advertise our new support for #RFC9421. Having a proposed standardized way to do that felt neat.

On the receiving end, I'm not sure we'd do any pre-flight requests to understand what an instance implements before acting on it, we'd probably rather stay conservative or do things like double-knock with caching, would be my guess. Might be different if it was something we could grab with a HEAD req.

Mitra v4.4.0 supports verification of RFC-9421 HTTP signatures. It is known to be compatible with @fedify, but I haven't tested it with Mastodon or Streams yet.
Outgoing requests are still signed according to the draft-cavage. I don't plan to implement double-knocking, but something like FEP-844e could be supported in the future, though this is not urgent.

My implementation of a parser is available in APx library.

@rfc9421 #rfc9421

RE: https://mitra.social/objects/01974018-9b83-c1ec-a109-24a72a579235

We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.

🌐 Cloudflare Workers support

Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.

New components

• WorkersKvStore: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environments
• WorkersMessageQueue: A message queue implementation leveraging Cloudflare Queues for reliable message processing

Key features

• Seamless integration with #Cloudflare's serverless runtime
• Automatic handling of queue message processing through Workers' queue() method
• Support for Node.js compatibility flag required for Fedify's cryptographic operations
• Manual queue processing via Federation.processQueuedTask() method

For a complete working example, see the Cloudflare Workers example in the Fedify repository.

🏗️ Federation builder pattern

Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:

• Deferred instantiation: Set up dispatchers and listeners before creating the federation object
• Better code organization: Avoid circular dependencies and improve project structure
• Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
• Modular setup: Build complex federations piece by piece before instantiation

The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.

🔐 HTTP Message Signatures (RFC 9421)

Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.

Double-knocking mechanism

To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:

1. Primary attempt: RFC 9421 (HTTP Message Signatures) for modern implementations
2. Fallback: Draft cavage version for legacy compatibility
3. Adaptive caching: The system remembers which version each server supports to optimize future requests

This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.

Interoperability testing

The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:

• Mitra 4.4.0: Successfully verified Fedify-generated RFC 9421 signatures
• Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)

These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.

🔍 WebFinger enhancements

Dedicated WebFinger lookup

The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.

🛠 Context API improvements

Context data replacement

The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.

🚀 Migration considerations

Backward compatibility

Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.

Node.js version requirement

Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.

New deployment options

For new deployments, consider leveraging Cloudflare Workers support for:

• Global edge deployment with low latency
• Serverless scaling and automatic resource management
• Integration with Cloudflare's ecosystem of services

🎯 Looking forward

Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.

For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.

#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #CloudflareWorkers

#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare #Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀

#ActivityPub #fedidev #fediverse #RFC9421 #CloudflareWorkers

Looking for #ActivityPub implementations with #RFC9421 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 #Fedify's main branch.

Any leads or connections would be greatly appreciated! 🙏

#fedidev

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

This implementation includes both signature generation and verification, meaning #RFC9421 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 #ActivityPub 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 #fediverse. 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#1-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!

#fedidev