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

[roy at nominet.org.uk]

Jelte Jansen <jelte at NLnetLabs.nl> wrote on 03/30/2009 02:00:55 PM:

> roy at nominet.org.uk wrote:
> > [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).
> >
>
> did we have a token/module mapping somewhere yet? we could take one from
> there ('Warning: no token specified. Using first token in
> configuration'). Or something like that.

That does lead to another dependency, right ? i.e. instead of specifying a
library, I now need to specify the path and name for the token/module
mapping place. Maybe we should indeed have a generic shared config.

> > [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.
> >
>
> Heh, this kind of contradicts your previous statement.

Well, this default has direct impact on the security realm, hence the
allergy for currently safe but future-weak defaults.

> I like *sane* defaults (whether from a configuration or hard-coded, or
both, in that
> order). But it may depend on what other uses you see for hsm-toolkit.

I have no use for hsm-toolkit other than opendnssec.

> > [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.
> >
>
> I don't see enough reasons to put a lot of work in that. OTOH, it
> doesn't look like a lot of work either. One advantage if you even want
> to use such a feature is that it could remember the PIN :)

ok.

> > [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.
> >
>
> I usually default to F4 (65537). I don't think identification of usage
> is a compelling argument to choose another exponent. But you may come up
> with more convincing reasons :) (otherwise my vote would be to use F4).


Heh. It was solely a 'because we can' argument. But lets stick with 65537.

Regards,

Roy Arends
Sr. Researcher
Nominet UK