opendnssec / SoftHSMv2

SoftHSM version 2
http://www.softhsm.org/
Other
769 stars 342 forks source link

CKA_PUBLIC_EXPONENT required for creating RSA private key in version 2.40 #432

Closed alexa-noxon closed 5 years ago

alexa-noxon commented 5 years ago

In C_CreateObject, RSA private keys are permitted to be created without specifying the public exponent.

From section 4.9.1 of the specification, Table 26, it seems that CKA_PUBLIC_EXPONENT is required starting in v2.40.

Tokens vary in what they actually store for RSA private keys. Some tokens store all of the above attributes, which can assist in performing rapid RSA computations. Other tokens might store only the CKA_MODULUS and CKA_PRIVATE_EXPONENT values. _Effective with version 2.40, tokens MUST also store CKA_PUBLICEXPONENT. This permits the retrieval of sufficient data to reconstitute the associated public key.

Is this planned to be enforced or will it be left as is for backward compatibility?

Thank you

rijswijk commented 5 years ago

On 5 Dec 2018, at 22:36, alexa@aws notifications@github.com wrote:

In C_CreateObject, RSA private keys are permitted to be created without specifying the public exponent.

From section 4.9.1 of the specification, Table 26, it seems that CKA_PUBLIC_EXPONENT is required starting in v2.40.

Tokens vary in what they actually store for RSA private keys. Some tokens store all of the above attributes, which can assist in performing rapid RSA computations. Other tokens might store only the CKA_MODULUS and CKA_PRIVATE_EXPONENT values. Effective with version 2.40, tokens MUST also store CKA_PUBLIC_EXPONENT. This permits the retrieval of sufficient data to reconstitute the associated public key.

Is this planned to be enforced or will it be left as is for backward compatibility?

It is almost impossible to know if applications that use PKCS #11 currently set this attribute correctly, and those applications that don't would certainly break if we change the behaviour. There are, however, no good reasons to set CKA_MODULUS but to then not set CKA_PUBLIC_EXPONENT. So I guess we could make enforcing this a compile-time option that is enabled by default.

Question though: it is generally not recommended to construct RSA private key objects using C_CreateObject, because all of the sensitive material would be provided in plain text. Typically, you either generate a key-pair or you unwrap a private key inside the token, in which case it would come from a PKCS #8 object that will have all of the relevant RSA data set. Could you indicate whether you have a specific use cases where you're importing plain keys so we can prioritise whether or not we should include this feature?

Best regards,

Roland

-- Roland M. van Rijswijk-Deij -- NLnet Labs

alexa-noxon commented 5 years ago

Thanks for getting back to me- I am using the SoftHSM test code to validate a security library and was concerned about not being able to easily reconstruct public keys.

Reading your answer, I agree that this should be a minority use case. This doesn't need to be prioritized (on my account at least!).