improvement: add signature_bits field to CA and signers

[jhart-cpi]

This change adds the ability to set the signature algorithm of the
CAs that Vault generates and any certificates it signs. This is a
potentially useful stepping stone for a SHA3 transition down the line.

Summary:

• Adds the field "signature_bits" to CA and Sign endpoints
• Adds support for SHA256, SHA384 and SHA512 signatures on EC and RSA
  keytypes.

[hashicorp-cla]

All committers have signed the CLA.

[sgmiller]

I like the idea, but if bit length that switches on algorithm is a bit opaque. I'd prefer to introduce a field that selects the algorithm based on the name and bit length. KeyBits is a bit different since it's more arbitrary than the possible hash lengths which are often fundamental to the hash function itself.

[jhart-cpi]

I like the idea, but if bit length that switches on algorithm is a bit opaque. I'd prefer to introduce a field that selects the algorithm based on the name and bit length. KeyBits is a bit different since it's more arbitrary than the possible hash lengths which are often fundamental to the hash function itself.

I had similar thoughts as well when I was writing this patch. In the end, my motivation for using a signature_bits field instead of a string/int combination was for (what are my assumptions about this code) motivations in this codebase for matching ECDSA and RSA signatures to the chosen key type, which would appear to be TLS compatibility. While technically possible to pair an EC key with a SHA256WithRSA signature, for example, this does break compatibility with TLSv1.1 and potentially a host of other devices.

Until the SHA3 family, SHAKE or some other alternative is realistically available, for simplicity and compatibility I chose this path instead of adding a string field or a string/int combination.

[sgmiller]

Okay, that seems reasonable. As long as it's possible to add a signature_hash or similar parameter to pick a different family in the future I don't object. If you could tackle that conflict I think we're good.

[pmmukh]

@jhart-cpi could you please rebase this branch once? after that, long as tests pass, this should be good to merge in.

[jhart-cpi]

@jhart-cpi could you please rebase this branch once? after that, long as tests pass, this should be good to merge in.

Done.