`algorithm` parameter does not make sense
Diggsey opened this issue · comments
Previously, the algorithm parameter contained an actual signature algorithm identifier. This was removed because the verifier might incorrectly use this when verifying the signature, which would leave it vulnerable, instead of determining it from the stored key. Now, the only allowed value for algorithm is hs2019.
Firstly, I think this is an odd stance to take: there are lots of ways to incorrectly implement this RFC such that verification would be vulnerable. (For example, none of the implementations I have seen allow the verifier to specify a minimum set of headers that must be included!) It's inconsistent to make this change without also being more prescriptive about how signatures are verified to avoid the other more common issues.
Secondly, if specifying the algorithm is considered too much of a risk, then this field should be removed entirely. There are a few reasons:
hs2019serves no purpose, as the RFC does not prescribe a minimum set of supported algorithms corresponding to this identifier.- If version information is required, it could be provided via a
versionfield and avoid being conflated with the algorithm to use. - As long as
algorithmis listed as a field in the spec, implementations are just as likely to use it incorrectly when verifying signatures. The problem of "implementations may not follow this rule in the spec" cannot be solved by adding another rule.
In short, either algorithm should be removed entirely, or it should be restored to contain the actual algorithm name.
We just started working on this spec with the http working group. The draft will be uploaded soon on
And here I shared a commentable gdoc to kick off some discussion with the editors:
I think this issue and many others are related to the goal of http-signature to be somewhat backward-compatible.
