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

[roy at nominet.org.uk]

Sorry for top (and re-) posting, but I'd like to have some input on the
square brackets below.

Roy Arends wrote on 03/25/2009 12:41:47 AM:

> 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
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>