Fix handling of SignatureBits for ECDSA issuers

[cipherboy]

When adding SignatureBits control logic, we incorrectly allowed
specification of SignatureBits in the case of an ECDSA issuer. As noted
in the original request, NIST and Mozilla (and others) are fairly
prescriptive in the choice of signatures (matching the size of the
NIST P-curve), and we shouldn't usually use a smaller (or worse, larger
and truncate!) hash.

Ignore the configuration of signature bits and always use autodetection
for ECDSA like ed25519.

Signed-off-by: Alexander Scheel <[email protected]>

---

This definitely warrants a changelog entry, but not sure if we need anything else? This was added in 1.10.0, we'll backport this to 1.10.1, fixing the issue. It only presently works on roles (it should probably be added to the other endpoints later?).

Ticket: VAULT-5707

[kitography]

Nice test, the only confusing part of this fix is not in code that you changed.

[kitography]

Confused looking at this list of curves below: we explicitly set ECDSAWithSHA256 for P224 and 256 (but not P192 which is set by default)?

I think it would be cleaner/safer if we added P192 to the first case, then either error if we don't recognize the alrogirthm?

[cipherboy]

We actually restrict it to at least P-224:

vault/sdk/helper/certutil/helpers.go

Lines 690 to 694 in 74248e1

	case "ec":
	_, present := expectedNISTPCurveHashBits[keyBits]
	if !present {
	return fmt.Errorf("unsupported bit length for EC key: %d", keyBits)
	}

As Go lacks support for P-192: https://github.com/golang/go/blob/master/src/crypto/elliptic/elliptic.go#L442-L447 and https://pkg.go.dev/crypto/elliptic

So there's no way to do this comparison.

What is the hash function for P-192 anyways? This makes me think it is the insecure SHA-1 which isn't... good? :-)