Add explicit HMAC key type

[jsha]

Right now HMAC keys are []byte. That's nice and simple, but it means that they do not carry type information about which algorithm they are meant to be used with. So when verifying a JWS / JWT signature using HMAC, the decision to use HS256, HS384, or HS512 is determined by the submitted JWS "alg" header instead of the application developer.

To solve that, we should wrap HMAC keys in a type that indicates the appropriate algorithm, e.g. type HS256Key struct { key: []byte }.

[jsha]

On thinking about it some more, I realized public key verification has the same problem: the key is trusted to provide the general key type (RSA, ECDSA, Ed25519), but specifics of signing like which hash and which RSA signing algorithm to use are specified by user-supplied data (the "alg" header).

I think the solution is this:

Verify currently takes a big list of types behind an interface{}:

// The verificationKey argument must have one of these types:
//   - ed25519.PublicKey
//   - *ecdsa.PublicKey
//   - *rsa.PublicKey
//   - *JSONWebKey
//   - JSONWebKey
//   - []byte
//   - Any type that implements the OpaqueVerifier interface.

Instead I think it should take exactly one concrete type, *JSONWebKey . That carriers its own Key interface{} , with a similar list of types:

	// Key is the Go in-memory representation of this key. It must have one
	// of these types:
	//  - ed25519.PublicKey
	//  - ed25519.PrivateKey
	//  - *ecdsa.PublicKey
	//  - *ecdsa.PrivateKey
	//  - *rsa.PublicKey
	//  - *rsa.PrivateKey
	//  - []byte (a symmetric key)

But it also carries its own Algorithm field, which allows disambiguating HS256 vs HS384 etc.

For convenience there would be constructors that build a JSONWebKey from parts, e.g. HMACKey(key []byte, alg SigningAlgorithm) *JSONWebKey

But also this is significantly more churn, it's not strictly needed to allow correct applications (it just encourages more correct applications) and we don't have to target everything for the v4 release. So putting this on hold for now.