(following on from State of HTTP Signatures?)
The current version of the HTTP Signatures spec requires that the signature algorithm be “derived from metadata associated with ‘keyId’”. As far as I know, no implementation actually did this, and instead assumed all signatures were rsa-sha256 (of those that even updated to the new drafts).
Note that older versions of the spec included the algorithm in the signature, but this is insecure as malicious actors could specify a weaker algorithm than the real sender intended.
I propose the following solution, roughly based on the CCG’s Security Vocabulary:
- Add a
signatureAlgorithmfield to the
publicKeyfield on Actors, with a value chosen from the list in RFC 6931, most likely
- Parse incoming signatures based on the
signatureAlgorithmvalue, with a subset of possible algorithms defined by the implementation. If the key is not present, default to rsa-sha256, since this is what current implementations use.
I’ve implemented this with support for both rsa-sha256 and rsa-sha512 for incoming signatures in lotide, but would like to hear from other implementers in case there’s a better path. Additionally, what other signature algorithms would be worthwhile to add support for?