[Opendnssec-develop] hsm-toolkit update, and some open questions

[roy at nominet.org.uk]

Dear list,

hsm-toolkit has been updated. I would like some discussion on the points
listed below between the square brackets.

The command line arguments are as follows:

hsm-toolkit -l pkcs11-library [-s slot] [-p pin] [-G [-b keysize]] [-D
UUID-string]

-l pkcs11-library specifies the PKCS11 library provided by the HSM
provider. As an example, on my OSX based machine, using softHSM, I'd
specify: -l libsofthsm.dylib. There is no default, and thus has to be
specified (see [1])

-s slot is optional. If not given, it will find the first available slot,
containing a token.

-p pin is optional. If not given, it will ask for the user pin.

If no other arguments are given, hsm-toolkit lists some attributes (class,
modulus size, label and ID) of public and private key objects of the token.

-G generates one keypair (see [3]. If -b is not specified, the default
keysize is 1024 bit (see [2]). The CKA_ID is automatically generated, and
contains a Version 4 (random) UUID. The CKA_LABEL contains the canonical
form of the UUID. The user has no influence on either the CKA_ID or the
CKA_LABEL. The default public exponent e is 65537 (see [4])

-D destroys a keypair. The lookup value for the keypair is the UUID in
canonical form (for example -D 94be1f7c-b8b9-4f2e-8c3c-0173b24900f8 ). The
UUID is matched against the CKA_ID. Though a CKA_LABEL attribute of an
object generated by hsm-toolkit is a UUID in canonical form as well, it is
NOT used in locating objects.

examples (the pin is too short, I know)

To generate a key:

roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845-G -b 768
hsm-toolkit: Created RSA key pair object, labeled
7bdefa80-09bf-469c-883c-babfdad08443

To list the contents of a softhsm token:

roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845
hsm-toolkit: 2048-bit Public  key object,
label:f4fd3dbf-8b1b-446f-ad86-9b3a0ab46010,
id:f4fd3dbf8b1b446fad869b3a0ab46010
hsm-toolkit: 2048-bit Private key object,
label:f4fd3dbf-8b1b-446f-ad86-9b3a0ab46010,
id:f4fd3dbf8b1b446fad869b3a0ab46010
hsm-toolkit: 1024-bit Public  key object,
label:c617eb35-f9c0-41ce-af17-f39b05624930,
id:c617eb35f9c041ceaf17f39b05624930
hsm-toolkit: 1024-bit Private key object,
label:c617eb35-f9c0-41ce-af17-f39b05624930,
id:c617eb35f9c041ceaf17f39b05624930
hsm-toolkit: 768-bit Public  key object,
label:7bdefa80-09bf-469c-883c-babfdad08443,
id:7bdefa8009bf469c883cbabfdad08443
hsm-toolkit: 768-bit Private key object,
label:7bdefa80-09bf-469c-883c-babfdad08443,
id:7bdefa8009bf469c883cbabfdad08443

To destroy a keypair from a softhsm token:

roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845 -D
7bdefa80-09bf-469c-883c-babfdad08443
hsm-toolkit: Destroyed Public  key object:
7bdefa80-09bf-469c-883c-babfdad08443
hsm-toolkit: Destroyed Private key object:
7bdefa80-09bf-469c-883c-babfdad08443


I would like to have some closure on the following thoughts:

[1] Please discuss how we can circumvent this, as it is pretty annoying,
and remains probably the same for a very long time for a user. We could do
this via an environment setting, via a configuration file,  both (or yet
something else).

[2] Hard configured defaults will hurt eventually. This could also set this
via a configuration file, or come to think of it, no default at all. Please
discuss this as well.

[3] Feature request idea: do we need to be able to generate keys in bulk?
Say with an option for -G to generate X keypairs ? Since we don't need to
specify anything _per_key_ this seems feasible. This seems to fit the use
case for a large amount of zones.

[4] I understand from the world of cryptographers to avoid "3" as public
exponent, as there might be implementations that are susceptible to
Bleichenbacher's RSA signature forgery scheme due to sloppy padding. (see
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html ). It seems that
17 and 65537 are commonly used as a public exponent. I chose 65537, but
that was arbitrary. We could also use yet another, very obscure but fixed
exponent, solely to be able to identify which zones use OpenDNSSEC by the
public exponent in the DNSKEY.

Thanks for reading,

Regards,

Roy Arends
Sr. Researcher
Nominet UK