NodeBB and RFC 9421

I've been working (admittedly, with AI assistance) on HTTP signatures RFC 9421 support.

The work will be done in stages. The first step is ensuring NodeBB can handle receipt of activities signed under the new standard (with adequate fallback to draft cavage-12).

Afterwards NodeBB will begin sending out activities signed with both methods.

Question re: double knock for AP devs who have implemented... is there a specific reason 9421-signed is sent first, and then cavage-12? My understanding is the headers are separate — Signature-Input vs Signature, though there are two of the latter.

It seems possible to send both signatures at once.

@julian because most implementations still default to cavage, so it's the fastest path?

@julian@activitypub.space

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

we hit this exact thing in Welley.

you can't send both at once, and it's not because of Signature-Input. that header's fine, it's unique to 9421. the problem is the Signature header itself, both schemes want it, with totally different, incompatible contents. cavage fills it with keyId="...",headers="...",signature="...", and 9421 fills it with sig1=....

same header name, two languages that don't mix.

and if you try to send two Signature headers, HTTP is allowed to just squash repeated headers into one comma-joined value. so the receiver might see both jammed together, which is garbage to a cavage parser.

as for why 9421 goes first: no protocol rule says it has to, it's just a "prefer the new thing" move. lead with 9421, fall back to cavage only when needed, and as the network upgrades more first-knocks succeed until you can eventually drop cavage entirely.

one tip for when you get to sending: cache per-domain which scheme worked, otherwise you're doubling every delivery to un-upgraded peers forever. and only retry-with-the-other-scheme on an actual signature failure, don't re-knock on a 401 that just means you're blocked, or a 410 gone.

for what it's worth, your staging is spot on: receive-both first, dual-send later. that's exactly where Mastodon and we are too, everyone accepts both but still sends one

@nick @julian

Yes, it is shortened. The last sentence shown in Mastodon Web UI is:

> Question re: double knock for AP devs who have implemented... is there a specific reason 9421-signed is sent first, and then cavage-12?

I hadn't really noticed as it cut off right at the question mark

> @skavish@welley.social said:
>
> same header name, two languages that don't mix.

Yes, I was worried about this. I was hoping maybe cavage parsers were smart enough to only parse header values that match expected inputs, so sending two Signature headers would work, but knowing what I know, that's wishful thinking <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f605.png?v=22426bb3280" title="" />

Thanks for the detailed reply! Looking forward to testing in the next few days.

@smallcircles@social.coop indeed, we cut off at the end of a sentence and link out to the full page for Articles (although in this case it's not very long)

The cutoff is somewhere around 500 chars.