This repository was archived by the owner on Sep 21, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 21, 2026. It is now read-only.
feature proposal #18
Description
Activity
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.
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 ?