Re: [OpenCA-Devel] New HSM - Problems

[Michael Bell]

Hi,

Massimiliano Pala wrote:

I am trying to integrate a new HSM with OpenCA - it is from ERACOM (somebody has already experience with OrangeServer ?). I have created a new OpenCA::Token

called ERACOM and I have successfully used the Key/Certificate creation
process.

Ok, so the token works.

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 ?

Usually the people are a little bit to lazy and define the CA token as the default token. If you create now a new key for a CA operator then the default token is used - which is in fact the CA token. Simply define a normal (software) token (the name is not relevant) and set it as default token. BTW this notice is also in the OpenCA guide at minimum for Luna (http://www.openca.info/docs/guide/html_chunked/ch04s02.html#id2823393)

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

the problem is that:

normal cakey.pem file). If I use the same command to generate CA/RA keypairs

1- It may be impossible to export the keys (depends on the HSM config)

HSM key generation should only be used for CA keys and not for operator keys.

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.

http://www.openca.info/docs/guide/html_chunked/ch11.html
http://www.openca.info/docs/guide/html_chunked/ch04s02.html

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
[EMAIL PROTECTED]   D-10099 Berlin
_______________________________________________________________

No, do not handle this in the token module. The logical unit for this is the token. The idea of the token design is that we have different tokens for different usages. The CA token should only be used for CA operations. The default token should be used for normal operations like signature verification and key generation for user certs. So please define another token for normal operations which is different from the CA token and then set this token as the default token. Perhaps we should merge the token description of the technology and design guide.

smime.p7s
Description: S/MIME Cryptographic Signature