Reminder : [Opendnssec-develop] hsm-toolkit update, and some open questions
roy at nominet.org.uk
roy at nominet.org.uk
Mon Mar 30 11:39:02 UTC 2009
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
> -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 )
> -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
> modulus size, label and ID) of public and private key objects of the
> -G generates one keypair (see . If -b is not specified, the default
> keysize is 1024 bit (see ). 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 )
> -D destroys a keypair. The lookup value for the keypair is the UUID in
> canonical form (for example -D 94be1f7c-b8b9-4f2e-8c3c-0173b24900f8 ).
> 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
> 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
> To list the contents of a softhsm token:
> roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845
> hsm-toolkit: 2048-bit Public key object,
> hsm-toolkit: 2048-bit Private key object,
> hsm-toolkit: 1024-bit Public key object,
> hsm-toolkit: 1024-bit Private key object,
> hsm-toolkit: 768-bit Public key object,
> hsm-toolkit: 768-bit Private key object,
> To destroy a keypair from a softhsm token:
> roy$ ./hsm-toolkit -l libsofthsm.dylib -p 97123845 -D
> hsm-toolkit: Destroyed Public key object:
> hsm-toolkit: Destroyed Private key object:
> I would like to have some closure on the following thoughts:
>  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
> this via an environment setting, via a configuration file, both (or yet
> something else).
>  Hard configured defaults will hurt eventually. This could also set
> via a configuration file, or come to think of it, no default at all.
> discuss this as well.
>  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.
>  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
> 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,
> Roy Arends
> Sr. Researcher
> Nominet UK
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
More information about the Opendnssec-develop