Open dlongley opened 3 years ago
the utf8 thing has been mentioned before and I'm looking into it. The SHA-512 comes from the definition for hs2019
:
For example, assume that the
algorithm
value is "hs2019" and thekeyId
refers to an EdDSA public key. This would signal to the application that the signature string construction mechanism is the one defined in Section 2.3: Signature String Construction [9], the signature string hashing function is SHA-512, and the signing algorithm is Ed25519 as defined in RFC 8032 [RFC8032], Section 5.1: Ed25519ph, Ed25519ctx, and Ed25519. The result of the signature creation algorithm should result in a binary string, which is then base 64 encoded and placed into thesignature
value.
and the exact mention from the registry:
Algorithm Name: hs2019 Status: active Canonicalization Algorithm: [RFC_THIS_DOCUMENT], Section 2.3: Signature String Construction [22] Hash Algorithm: RFC 6234 [RFC6234], SHA-512 (SHA-2 with 512-bits of digest output) Digital Signature Algorithm: Derived from metadata associated with
keyId
. Recommend support for RFC 8017 [RFC8017], Section 8.1: RSASSA-PSS, RFC 6234 [RFC6234], Section 7.1: SHA-Based HMACs, ANSI X9.62-2005 ECDSA, P-256, and RFC 8032 [RFC8032], Section 5.1: Ed25519ph, Ed25519ctx, and Ed25519.
It looks like the CLI tool is doing an additional SHA-512 hash of the content before feeding it to Ed25519 (which is Pure EdDSA). I can't tell if that's correct or not based on the spec. I also can't tell what the spec intends ... as doing an additional hash on the content is unnecessary with Pure Ed25519 and removes some of its benefits. Perhaps this additional hashing was intentional, however, to enable better privacy with external HSM systems? It's all a bit unclear.
https://github.com/digitalbazaar/http-signature-header/blob/master/bin/util.js#L108-L111
Either way, the tool converts a digets to 'utf8' and then back again ... when it could just do
digest()
and get the Buffer directly.