Update to adhere to RFC 9421

[DavidLievrouw]

The Internet Draft is now an official IETF RFC.

First discovered noticeable changes, impacting this library:

• The (created), (expires) and (request-target) pseudo-headers have been replaced by specialty fields @request-target and @signature-params.
  • The @signature-params specialty field should be part of the composed signature string. This includes the values of the legacy (created) and (expires) pseudo-headers.
• The signature used to be added to the Authorization-header of the request message. In the new spec, a combination of Signature and Signature-Input headers are used instead. This will allow for multiple signatures in the future.
• HTTP header fields must use LOWERCASED field names, not case-insensitive ones.
• Simplify combination of encryption and hashing algorithms to those from the draft, and specify them in the alg field:
  • rsa-pss-sha512
  • rsa-v1_5-sha256
  • hmac-sha256
  • ecdsa-p256-sha256

As you can see, major breaking changes here. And I have not yet investigated the whole RFC.

We will need to provide an upgrade path for existing consumers, especially concerning the enc/hash algorithm combinations.

Other changes will be handled in separate issues:

• 28 Support for Dictionary Structured Field Members.

• 29 Support for List prefixes.

• 30 Support for Multiple signatures in a single request.

[DavidLievrouw]

• Enable padding mode setting for RSA
• Write alg field correctly (no longer hs2019)
• HTTP header fields must use LOWERCASED field names, not case-insensitive ones
• Remove (expires) and (created) pseudo headers
• Replace usage of (request-target) with @request-target specialty field
• Create @signature-params specialty field and add it to the composed signature string
• Sign and verify using the Signature and Signature-Input headers
• Update conformance tests
• Add support for multiple signatures
• Add support for Dictionary Structured Fields
• Add support for List Prefixes

[henkli]

Thanks for the great library. Any thoughts on if/when the library could be updated to work with a more recent version of the standard?

[DavidLievrouw]

Well, unfortunately, these changes essentially mean a major rewrite. For example, if you take a look at the acceptance and conformance tests, none of them are correct, when you adhere to the latest version of the draft.

I would prefer to wait until the standard becomes an RFC, and not an Internet Draft, as it is now. To avoid having to rewrite it again.

Not sure where this will evolve to. I am limiting the work to keeping it up-to-date, e.g. adding target framework .NET 8 in the near future, and updating third-party dependencies.

[DavidLievrouw]

The draft is now an official RFC: https://www.rfc-editor.org/rfc/rfc9421.html

Unfortunately, this means an epic rewrite. Unsure when I will get an opportunity to embark on this new endeavor.