search

w3c-ccg / http-signatures

Signing HTTP Messages specification
https://w3c-dvcg.github.io/http-signatures/
Other
34 stars 9 forks source link

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

Open dlongley opened 5 years ago

dlongley commented 5 years ago

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.

dlongley commented 5 years ago

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

ioggstream commented 5 years ago

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

liamdennehy commented 5 years ago

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 https://github.com/w3c-dvcg/http-signatures/issues/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.