feature proposal

[poolpOrg]

hellow @jbowes,

For my own uses, I have experimented with a change which I'd like to know if you're interested in before I spend more time on it for a proper PR.

Long story short, whenever you want to add support for a specific elliptic curve and a specific hasher function, you are forced to implement a specific private signer & verifier, as well as a specific public signer & verifier functions (ie: signEcdsaP256Sha256, verifyEcdsaP256Sha256, WithSignEcdsaP256Sha256, WithVerifyEcdsaP256Sha256).

I implemented WithSignEcdsa(), WithVerifyEcdsa, signEcdsa & verifyEcdsa which take an additional crypto.Hash parameter and use key.Curve.Params().Name and crypto.Hash.String() to infer the algorithm. With this, I could easily switch between curves and hash functions to support combinations that are currently unsupported in your package.

Is this something you'd be interested in ?

[jbowes]

hi!

yes, i am interested. My intent was to have builtin implementations for the default combinations in the spec's registry, but then allow for arbitrary signing/verification outside of the default registry.

so something like: ```go

type Signer interface {
Sign(in io.Reader) ([]byte, error)
}

func WithSigner(alg string, signer Signer) signatureOption

(and the same for verifier) seems about right to me. Then consumers would be responsible for bundling up pre-hashing and signing/verifying into a single interface.