Closed bblfish closed 3 years ago
It think that the problem I described above is no longer valid with the April release of Signing HTTP Messages v03. See @jricher's mail to the HTTP Bis WG.
@bblfish Sorry for the confusion between the versions, we (the HTTPSig editors) are tackling the biggest changes a piece at a time and that can lead to confusion like this! The changes in -03 signal the intended direction of the spec: separate specification of the key identifier and algorithm, for implementations that need to specify that. If you can get both from just the key, that's also allowed. (this is the "hs2019" style behavior)
Also, previously the algorithm and other content was not covered under the signature which lead to some possible substitution attacks, but this has all been addressed in -02 so the old motivation for deprecating all the specified algorithms has also gone away.
We welcome any additional feedback on the HTTP Sig spec to make sure that it's applicable across a wide variety of use cases like this.
Ah great, to hear that. I understand why moving the signature to its own separate header was such an important move. I should be able to provide some feedback on the draft pretty soon, now that I have implemented RFC8941.
I think I found a bug in "Signing HTTP Messages", and reported it here: https://github.com/httpwg/http-extensions/issues/1456
But I think this issue can be closed, as the new spec allows the algorithms to be specified again.
In Signing HTTP Messages 02 the only remaining algorithm is named
hs2019
. This algorithm actually covers nearly all the others, but shows a change in direction of the meaning of thekeyId
. Whereas until draft-cavage-10 thekeyId
referred to a cryptographic key, e.g. an RSA key, and the signer then had to specify the algorithm in the signature header,The new Signing HTTP Messages states that
Draft-cavage-12 has the following example
and the latest 02 IETF spec has
So essentially the type of key used and the hashing function data have been removed, and are meant to be stored with the key.
This seems to have been introduced to remove some attack vectors related I guess to the signature being replaced with a another valid one on a easier to crack hash function.
Consequence
In the HttpSig document I have the keyId as a URL which dereferences to the following description:
It should I think be something closer to this:
This may mean that
did:key
no longer quite fit - if that is they only refer to keys (but let us what the did:key folks give as answer to my question).Is there a name for such an
cryptoKey × hashingAlgo
pair?