How to upgrade supported HTTP Sig version(s)

[snarfed]

How should we advise projects to upgrade the version(s) of HTTP Sigs that they generate and validate?

Related: #1, #3, #17

@nightpool, I'm pretty sure you know more about this than me, https://github.com/swicg/activitypub-http-signature/issues/1#issuecomment-1927992088 , can I ask you to take a first pass at text here?

[snarfed]

@nightpool friendly ping! ok if you don't have a draft of text here yet; I'm just checking if you're still interested in working on this, and the report in general.

[snarfed]

Initial draft text below. Please review and revise!

---

The HTTP Signatures standard has made a few backward-incompatible changes on its path to becoming a full Proposed Standard RFC. Many fediverse servers currently handle older versions of the standard and aren't yet compatible with the final (httpbis-19) version. Here's advice on how to implement HTTP Signatures so as to be compatible with as many different servers as possible.

The primary technique we recommend is "double-knocking." First, try generating or verifying an HTTP Signature with one version, ideally (but not necessarily) the latest. If the remote server rejects that signature, eg with an HTTP 401 response, or the incoming signature doesn't verify, try with another version. Repeat until a signature passes or you've tried all supported versions.

(Many fediverse servers do process incoming activities asynchronously, but they generally still verify signatures synchronously, so double knocking is still viable when delivering activities to remote inboxes.)

Here's a list of ways to check for different versions, in descending order:

• Does the request have the Signature-Input HTTP header? This was only added in the later versions of the standard, notably after cavage-12. The RFC itself advises this in its appendix on backward compatibility. If Signature-Input is present, and the signature fails, try removing it and using cavage-12 instead.
• Does the signature use the hs2019 placeholder algorithm? This was added in cavage-12, then removed again in later versions. It's not present in the final proposed standard. If the signature uses hs2019 and fails, try again with rsa-sha256.
• Does the signature include the (request-target), (created), or (expires) pseudo-headers? If so, and the signature fails, try replacing them with the Date and/or Host headers.