improvement: add signature_bits field to CA and signers #11245
Conversation
|
|
|
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. |
|
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. |
|
@jhart-cpi could you please rebase this branch once? after that, long as tests pass, this should be good to merge in. |
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.
ghost
force-pushed
the
ext_signatures
branch
from
f16ee42 to
f07bb6a
Compare
Done. |
When using an ECDSA signature with a NIST P-Curve, we should follow recommendations from BIS (Section 4.2) and Mozilla's root store policy (section 5.1.2) to ensure that arbitrary selection of signature_bits does not exceed what the curve is capable of signing. Related: hashicorp#11245 Signed-off-by: Alexander Scheel <[email protected]>
) * Restrict ECDSA signatures with NIST P-Curve hashes When using an ECDSA signature with a NIST P-Curve, we should follow recommendations from BIS (Section 4.2) and Mozilla's root store policy (section 5.1.2) to ensure that arbitrary selection of signature_bits does not exceed what the curve is capable of signing. Related: #11245 Signed-off-by: Alexander Scheel <[email protected]> * Switch to certutil.ValidateKeyTypeSignatureLength(...) Replaces previous calls to certutil.ValidateKeyTypeLength(...) and certutil.ValidateSignatureLength(...) with a single call, allowing for curve<->hash validation. Signed-off-by: Alexander Scheel <[email protected]> * Switch to autodetection of signature_bits This enables detection of whether the caller manually specified a value for signature_bits or not; when not manually specified, we can provision a value that complies with new NIST P-Curve policy. Signed-off-by: Alexander Scheel <[email protected]> * Select hash function length automatically Due to our change in behavior (to default to -1 as the value to signature_bits to allow for automatic hash selection), switch ValidateKeyTypeSignatureLength(...) to accept a pointer to hashBits and provision it with valid default values. Signed-off-by: Alexander Scheel <[email protected]> * Prevent invalid Curve size lookups Signed-off-by: Alexander Scheel <[email protected]> * Switch from -1 to 0 as default SignatureBits Signed-off-by: Alexander Scheel <[email protected]> * Add changelog entry Signed-off-by: Alexander Scheel <[email protected]>
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:
keytypes.