Add algorithm hs2019 to createAuthzHeader.

[aljones15]

Adds hs2019 to the authz headers:

Signature keyId="did:key:z6Mkkhu5bsDV391yVtYgUEBpFa2D5eX68gnnChYZNZtaPvmf#z6Mkkhu5bsDV391yVtYgUEBpFa2D5eX68gnnChYZNZtaPvmf",algorithm="hs2019",headers="(key-id) (created) (expires) (request-target) host capability-invocation",signature="5r0pUbSekVMDVzSc4hIdwQmuDRm1KEsWkEA8EIsafOy7K9x+1wWbtTKdubkda1/eDB2qJjpgfZ9LNnAuNNu5Aw==",created="1602254205448",expires="1602254805448"

this also ensures the tests are using the latest http-signature-zcap-verify

Tests:

• All unit tests pass
• Have tried this in a branch of edv-client with no errors so far.

This corrects an error @msporny found here: https://github.com/decentralized-identity/secure-data-store/issues/113

[msporny]

Great @aljones15, thank you!

I expect that we may also need to sign over the canonicalization value of "(canonicalization-algorithm) hs2019" -- but that's for later... we'll have to push that through the IETF HTTP WG.

[msporny]

The algorithm is unprotected, which probably needs to be fixed in a future PR.

[msporny]

Hmm... on second thought, why is this not going in the base http-signature library? That's where this belongs, right?

/cc @dlongley @davidlehn -- does "hs2019" go in the base http-signatures library?

[aljones15]

Hmm... on second thought, why is this not going in the base http-signature library? That's where this belongs, right?

/cc @dlongley @davidlehn -- does "hs2019" go in the base http-signatures library?

@msporny I can't seem to find a latest version of the spec that makes algorithm required. The latest one I could find is the one that expires Oct 12 2020 and in that spec algorithm is recommended (it was required in a 2014 spec). Is there a newer spec I need to look at?

[aljones15]

ok so sorry to harp on this one, but:

"algorithm"
RECOMMENDED. The "algorithm" parameter contains the name of the
signature's Algorithm, as registered in the HTTP Signature
Algorithms Registry defined by this document. Verifiers MUST
determine the signature's Algorithm from the "keyId" parameter
rather than from "algorithm". If "algorithm" is provided and
differs from or is incompatible with the algorithm or key material
identified by "keyId" (for example, "algorithm" has a value of
"rsa-sha256" but "keyId" identifies an EdDSA key), then
implementations MUST produce an error. Implementers should note
that previous versions of this specification determined the
signature's Algorithm using the "algorithm" parameter only, and
thus could be utilized by attackers to expose security
vulnerabilities. The default value for this parameter is
"hs2019".

https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00#section-4.1

so it says it is RECOMMENDED, but has a default value?

[OR13]

@aljones15 yes, the spec is not super helpful here...

https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00#section-5.1.2

recommended support for Ed25519 is the only part that is relevant IMO.

I would interpret the spec as follows:

use hs2019, throw if you encounter a key that is not Ed25519 for now.

[aljones15]

@aljones15 yes, the spec is not super helpful here...

https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00#section-5.1.2

recommended support for Ed25519 is the only part that is relevant IMO.

I would interpret the spec as follows:

use hs2019, throw if you encounter a key that is not Ed25519 for now.

that's basically how the binary works:

https://github.com/digitalbazaar/http-signature-header/blob/80f2648e8b850100e1620a4c340fc613040bbb65/bin/util.js#L31-L44

[dlongley]

Accepting this because the createAuthzHeader used here is a helper function that does not do anything with the algorithm used. This allows other algorithms to be used in combination with different canonicalization mechanisms -- but this lib uses the only one provided by the underlying library at the moment -- and so hs2019 matches that usage.

[mattcollier]

@aljones15 Please address merge conflicts and add a changelog entry at your convenience.

[aljones15]

@mattcollier this was intended to be part of the implementation of version 13 of the http sigs spec. However I guess this can be added as we are using hs2019 and adding it would probably help in the future if we decide to change algorithm. This is not a priority for me, but will be addressed in the future.