Order of signature parameters at verify time

[mariusor]

Hello, I've done some more work integrating httpsig with my GoActivityPub library, and I've tried to use the RFC9421 examples as validation tests.

One of the issues I encountered is that httpsig uses a hard-coded ordering of the parameters for the signature verification, instead of using the order as it's listed in the Signature-Input header.

So using Example B.2.6, the string to sign is:

"date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST
"@path": /foo
"@authority": example.com
"content-type": application/json
"content-length": 18
"@signature-params": ("date" "@method" "@path" "@authority" "content-type" "content-length");keyid="test-key-ed25519";created=1618884473

instead of the value in the example (the createdat and keyid are reversed)

"date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST
"@path": /foo
"@authority": example.com
"content-type": application/json
"content-length": 18
"@signature-params": ("date" "@method" "@path" "@authority" "content-type" "content-length");created=1618884473;keyid="test-key-ed25519"

So I want to know if a PR that fixes this ordering issue would be useful.

---

The example doesn't work as stated yet as httpsig ignores the @path, to fix that see #13.

[mariusor]

Another low effort possibility is to change the order to the one shown in the initial contents for the "HTTP Signature Metadata Parameters" registry which seems to be the order used in the examples: alg, created, expires, keyid, nonce, tag.

I have a version of this ready in this branch.

[mariusor]

And finally I have a branch that contains also the logic for preserving the sort order.

I'm not entirely satisfied with the introduction of the new SortOrder member in the sigparams.Params struct, but I didn't find a better way to propagate the order.

[chrnorm]

thankyou for opening this! I am curious if there is any wording in the spec on whether implementations MUST or SHOULD have specific ordering. in any case, i think aligning with the spec’s examples is ideal (link) we can cut a major release od this package to account for the change

[chrnorm]

I’d also certainly accept a contribution to upstream the validation tests used in the RFC!

[mariusor]

I am curious if there is any wording in the spec on whether implementations MUST or SHOULD have specific ordering.

Not as far as I've seen. The only reference to the order was about how changing the order modifies the resulting signatures.

I'll see if I can come up with a PR that includes some of the tests in the RFC, but one problem is the fact that the default Verifier functionality only tries to validate for a known tag. Some of the test cases don't have tags, so the library would need more changes, that I'm not sure are compatible to the way you designed it.

For my own code I had to reimplement the verifier logic skipping the tag validation and just trying to verify against all present signatures until one succeeds or all fail.