Signing string should include keyId and algorithm (if present) via pseudo headers

[Dave Longley]

In order to prevent attackers from changing the keyId and algorithm parameters in the signature string, these should be included via pseudo headers in the signing string.

[Dave Longley]

Perhaps keyId should use the pseudo header (key-id) to match other kebab case things -- and algorithm would be (algorithm).

[Roberto Polli]

I think we could associate to every algorithm a Signature-String construction.

In this way we achieve some algorithm agility and define new Signature-Strings

[Liam Dennehy]

Perhaps keyId should use the pseudo header (key-id) to match other kebab case things -- and algorithm would be (algorithm).

I would prefer every signature parameter should have the option of inclusion in the Signing String. If we formulate my proposed overhaul of the header parameter, then we can stop making exceptions and new rules:

(*): signature parameter e.g. (created), (keyId)
:*: http pseudo-header e.g, :path, :method
*: HTTP header

I could then end up with:

headers="(created) (keyId) :method :path content-type digest"

... without having to make special rules since the values are known and canonicalisation is trivial.

This means we can include as much of the message and parameters as we like, and every time we add/tweak an existing parameter it's just incorporated.

This all depends on our stance on Breaking Changes and backwards compatibility #88, but I don't see how we're not just going to end up re-arguing new tweaks and new rules until the end of time, and adding more complexity to this spec along the way.