pki: When a role sets key_type to any ignore key_bits value when signing a csr #16246
Conversation
- Bypass the validation for the role's key_bits value when signing CSRs if the key_type is set to any. We still validate the key is at least 2048 for RSA backed CSRs as we did in 1.9.x and lower.
stevendpclark
added
bug
stevendpclark
force-pushed
the
stevendpclark/vault-6913-fix-pki-signing
branch
from
b2f8bb4 to
a4cfdcc
Compare
| return nil, errutil.InternalError{Err: fmt.Sprintf("unknown internal error updating default values: %v", err)} | ||
| } | ||
|
|
||
| // We're using the KeyBits field as a minimum value, and P-224 is safe | ||
| // and a previously allowed value. However, the above call defaults | ||
| // to P-256 as that's a saner default than P-224 (w.r.t. generation). | ||
| // So, override our fake Role value if it was previously zero. | ||
| if actualKeyType == "ec" && roleBitsWasZero { | ||
| if actualKeyType == "ec" { |
There was a problem hiding this comment.
This doesn't quite look right? If a role's Keybits was 256, and we were using P-256 why would we change that without testing it was 0 (or any)? Also comment no longer looks right.
There was a problem hiding this comment.
Agreed all this code is a tad confusing. The api docs specify the following
signing existing CSRs, any can be specified to allow keys of either type and with any bit size (subject to >1024 bits for RSA keys).
So we are within the any block so we are resetting the minimum size of key_bits no matter what the role had as a value to the lowest values we feel comfortable supporting for EC keys like we do for RSA keys.
I'll tweak the comment a bit dropping the "if it was previously zero" that I missed.
There was a problem hiding this comment.
Slack conversation:
Kit Haines
4:46 PM
I’m no longer sure if we are referring to “any” as keyBits or keyType
4:47
if we have set keyType “any” and keyBits “256" would we want to update that on the role?
4:47
or is that role not saved?
Steve Clark
4:47 PM
ha, yeah okay. When keyType == ‘any’ basically we just enforce mins for key bits no matter what the role says
4:48
That role that we update in the code you are seeing it thrown away
4:49
Alex had a different fix which might be clearer, I’m not sure. He was going to change the getRole function to always return a value of 0 for KeyBits if the role had a KeyType == ‘any’
Kit Haines
4:50 PM
^ I think I’d fine that clearer, but given we are throwing away the changes, I guess it doesn’t actually matter
| return nil, errutil.InternalError{Err: fmt.Sprintf("unknown internal error updating default values: %v", err)} | ||
| } | ||
|
|
||
| // We're using the KeyBits field as a minimum value, and P-224 is safe | ||
| // and a previously allowed value. However, the above call defaults | ||
| // to P-256 as that's a saner default than P-224 (w.r.t. generation). | ||
| // So, override our fake Role value if it was previously zero. | ||
| if actualKeyType == "ec" && roleBitsWasZero { | ||
| if actualKeyType == "ec" { |
There was a problem hiding this comment.
Slack conversation:
Kit Haines
4:46 PM
I’m no longer sure if we are referring to “any” as keyBits or keyType
4:47
if we have set keyType “any” and keyBits “256" would we want to update that on the role?
4:47
or is that role not saved?
Steve Clark
4:47 PM
ha, yeah okay. When keyType == ‘any’ basically we just enforce mins for key bits no matter what the role says
4:48
That role that we update in the code you are seeing it thrown away
4:49
Alex had a different fix which might be clearer, I’m not sure. He was going to change the getRole function to always return a value of 0 for KeyBits if the role had a KeyType == ‘any’
Kit Haines
4:50 PM
^ I think I’d fine that clearer, but given we are throwing away the changes, I guess it doesn’t actually matter
There was a problem hiding this comment.
Yeah this makes sense to me now too. Thanks for picking this up @stevendpclark!
…ing a csr (#16246) * pki: When a role sets key_type to any ignore key_bits value when signing - Bypass the validation for the role's key_bits value when signing CSRs if the key_type is set to any. We still validate the key is at least 2048 for RSA backed CSRs as we did in 1.9.x and lower.
…ing a csr (#16246) (#16260) * pki: When a role sets key_type to any ignore key_bits value when signing - Bypass the validation for the role's key_bits value when signing CSRs if the key_type is set to any. We still validate the key is at least 2048 for RSA backed CSRs as we did in 1.9.x and lower. Co-authored-by: Steven Clark <[email protected]>
…ing a csr (#16246) * pki: When a role sets key_type to any ignore key_bits value when signing - Bypass the validation for the role's key_bits value when signing CSRs if the key_type is set to any. We still validate the key is at least 2048 for RSA backed CSRs as we did in 1.9.x and lower.
…ing a csr (#16246) (#16259) * pki: When a role sets key_type to any ignore key_bits value when signing - Bypass the validation for the role's key_bits value when signing CSRs if the key_type is set to any. We still validate the key is at least 2048 for RSA backed CSRs as we did in 1.9.x and lower. Co-authored-by: Steven Clark <[email protected]>
This addresses issue #16237.
When signing a CSR using /sign/<:role name> api method we validate that the CSR matches up with the role's
key_typeandkey_bitsvalues. If thekey_typeis set toany, these checks don't really make sense, and these checks were effectively bypassed when thekey_bitsvalue was set to current default value of 0.The issue that was missed was the default value for created role's
key_bitsparameter was changed in 1.10 from 2048 to 0. So effectively the fix we previously made within PR#14875 addressed the issue, but only when the role was created in Vault 1.10 and higher.Now we bypass the validation for the role's
key_bitsvalue when signing CSRs if thekey_typeis set toany. We still validate the key is at least 2048 for RSA backed CSRs as we did in 1.9.x and lower.