Hi, > Anyway I have a problem when it comes to the CA/RA Operator's certificates > and KeyPairs. I would like not to use the HSM partition (i.e. generate the > Key within the HSM) for RA/CA because due to configuration options, it > could be impossible to export them. Therefore I need a way to use > different > tokens when using the CA key or "other" keys... do you have encountered > the same problem with other HSMs? How did you solved this ?
I think it's more a feature than a bug that a key cannot be exported from the HSM. Why do you want it to be exportable? If this is really desired you could create the key outside the HSM, e. g. with OpenSSL and import the RSA key into the module, but I don't think this is how a CA should handle key material... Concerning RA officer keys I think these should not be kept in the HSM but in possession of the RA officer. Either in software or in a hardware token, depending on the desired security level. With the nCipher hardware it is possible to specify Engine support for RSA key generation, in this case the module's RNG is used for RSA key generation which in turn is done in software. I think this is quite sensible and OK for user keys. > In detail, the HSM need to use a command line tool to generate internally > a keypair and the openssl to generate the reference to the key (in the > normal cakey.pem file). This is similar to nCipher HSMs. > If I use the same command to generate CA/RA > keypairs > the problem is that: > 1- It may be impossible to export the keys (depends on the HSM config) > > 2- Each key is identified by a label assigned during the creation process > it is not possible to create more keypairs with the same label, anyway > in the token.xml configuration I have put only one KEY_ID option (the > one to be used with the CA) > The idea is to not modify the genKey command, instead, to have a way > within > the module which enables the two different behaviours. > The fastest solution would be the adoption of ad additional parameter to > the keyGen command in Tokens to identify the key "scope", e.g. CA/RA/Other > and then having the module to perform different actions. I'd suggest to configure the CA token to use the HSM, that way you can use HSM protected key for certificate and CRL issuance. The default token could be configured to use the OpenSSL (software) module but use the OpenSSL -engine option for genrsa to utilize the hardware RNG of the module. cheers Martin ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ OpenCA-Devel mailing list OpenCA-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-devel
