Confusing guidance on algorithm and key identification

[richanna]

The current draft encourages determining the Algorithm metadata property from the keyId field, both in the guidance for the use of algorithm and keyId, and the definition for the hs2019 algorithm and deprecation of the other algorithms in the registry. The current state arose from concern that a malicious party could change the value of the algorithm parameter, potentially tricking the verifier into accepting a signature that would not have been verified under the actual parameter.

Punting algorithm identification into keyId hurts interoperability, since we aren't defining the syntax or semantics of keyId. It actually goes against that claim, as we are dictating that the signing algorithm must be specified by keyId or derivable from it. It also renders the algorithm registry essentially useless. Instead of this approach, we can protect against manipulation of the Signature header field by adding support for (and possibly mandating) including Signature metadata within the Signature Input.

[OR13]

TL;DR we should sign the signature algorithm... like we sign JWS headers... How can we mandate this?

[jyasskin]

Propagating my jabber comment from today's interim meeting: I think draft-ietf-httpbis-message-signatures should say that specs for protocols built on this header MUST define how the keyId field maps to a key, and then that the key MUST determine the algorithm. That would let this document avoid algorithm identifiers entirely.

[OR13]

P-256 -> ES256 ? This approach might not work for keys that support multiple signature types, such as secp256k1.

[jricher]

Discussion in -03 and -04 should now be clearer in how to use the combination of algorithm and key identifiers within an application of this spec to do secure key and algorithm identification.