As a blockchain developer
I want to be able to use arbitrary key types when signing using a Hardware Security Module (HSM)
So that I can use any key type supported by Fabric
In order to ensure that signatures are in canonical format (with low S values), the current Go and Node HSM signer implementations assume that the signing keys in the HSM are P-256 -- or at least that they are elliptic curve keys with the same curve N order as P-256 keys -- to manipulate the signature returned by the HSM. In theory it is possible for other key sizes, curve types or encryption mechanisms to be used.
A more generic solution might be to allow a mapping function to be (optionally) specified when creating the HSM signer, which would be applied to the signature returned by the HSM. The default mapping function would be to ensure the canonical form of a P-256 ECDSA signature (as the code does today), with the user able to specify an appropriate function for whatever keys they use in their HSM.
An additional consideration for the Node implementation is that an appropriately sized pre-allocated Buffer needs to be passed to the call to C_Sign (or C_SignAsync). This needs to be a suitable size to contain the returned signature so the minimum size is dictated by the type of key used.
As a blockchain developer I want to be able to use arbitrary key types when signing using a Hardware Security Module (HSM) So that I can use any key type supported by Fabric
In order to ensure that signatures are in canonical format (with low S values), the current Go and Node HSM signer implementations assume that the signing keys in the HSM are P-256 -- or at least that they are elliptic curve keys with the same curve N order as P-256 keys -- to manipulate the signature returned by the HSM. In theory it is possible for other key sizes, curve types or encryption mechanisms to be used.
A more generic solution might be to allow a mapping function to be (optionally) specified when creating the HSM signer, which would be applied to the signature returned by the HSM. The default mapping function would be to ensure the canonical form of a P-256 ECDSA signature (as the code does today), with the user able to specify an appropriate function for whatever keys they use in their HSM.
An additional consideration for the Node implementation is that an appropriately sized pre-allocated Buffer needs to be passed to the call to
C_Sign(orC_SignAsync). This needs to be a suitable size to contain the returned signature so the minimum size is dictated by the type of key used.