add RSA key size to SignatureAlgorithm

[jgreeer]

Summary

This PR adds support for having separate SignatureAlgorithm values for different key sizes. It adds a field rsa_key_size to the SignatureAlgorithm struct. We create a static SignatureAlgorithm struct for each combination of hash (SHA256, SHA384, SHA512) + key size (2048, 3072, 4096) adding 6 new algorithms. As a side effect, we have to pass rsa_key_size: None to the other algorithm structs.

The reason for this change is in key_pair.rs, you can now use the generate_for method to generate RSA key pairs of different key sizes by giving different SignatureAlgorithm arguments. This removes the need for generate_rsa_for, so we deprecate it in the same way RcgenError was. Since RsaKeySize is always used now, we removed the aws-lc-rs and crypto gating.

The rsa_key_size field is not used it the identity of the key, because it would mess up loading the key, and we don't want to mess with the OID. At load time, like in from_der_and_sign_algo, the user can give an RSA SigAlg value of any key size since the key size is later retrieved using rsa_key_pair_public_modulus_len.

Tests

We add a test in lib.rs to verify that RSA algs of different key sizes are equal to each other.

[djc]

I think this makes sense with some tweaks?

[djc]

Please squash the commits into a single one.

[jgreeer]

@djc i think this is good to merge now, i've integrated the changes from #453 and e6c421b

[cpu]

I'm a bit hesitant about this branch. I don't think we should continue to conflate signature identity with key generation policy, I think they should be modeled separately. Have you looked at what that might involve as a potential alternative? I was giving similar feedback in #448 (comment)

[jgreeer]

I'm a bit hesitant about this branch. I don't think we should continue to conflate signature identity with key generation policy, I think they should be modeled separately. Have you looked at what that might involve as a potential alternative? I was giving similar feedback in #448 (comment)

that's fair. this PR seems to go in the opposite direction of the feedback you gave. we're ultimately just trying to get rid of generate_rsa_for and instead have the functionality in generate_for. i think splitting SignatureAlgorithm into two is a good idea. maybe as an alternative we have another enum, something like KeyPairAlgorithim, that is only used as the argument to the generate function. i think this would achieve the clearest seperation of which enum is supposed to do what. or i guess it would probably have another name since we're getting rid of KeyPair.

[djc]

that's fair. this PR seems to go in the opposite direction of the feedback you gave. we're ultimately just trying to get rid of generate_rsa_for and instead have the functionality in generate_for. i think splitting SignatureAlgorithm into two is a good idea. maybe as an alternative we have another enum, something like KeyPairAlgorithim, that is only used as the argument to the generate function. i think this would achieve the clearest seperation of which enum is supposed to do what. or i guess it would probably have another name since we're getting rid of KeyPair.

Yup -- sorry for leading you astray. Do you have a chance to implement what @cpu was proposing in #448?

[jgreeer]

that's fair. this PR seems to go in the opposite direction of the feedback you gave. we're ultimately just trying to get rid of generate_rsa_for and instead have the functionality in generate_for. i think splitting SignatureAlgorithm into two is a good idea. maybe as an alternative we have another enum, something like KeyPairAlgorithim, that is only used as the argument to the generate function. i think this would achieve the clearest seperation of which enum is supposed to do what. or i guess it would probably have another name since we're getting rid of KeyPair.

Yup -- sorry for leading you astray. Do you have a chance to implement what @cpu was proposing in #448?

sure!