[Opendnssec-develop] hsm-toolkit update, and some open questions
roy at nominet.org.uk
roy at nominet.org.uk
Mon Mar 30 13:04:13 UTC 2009
Jelte Jansen <jelte at NLnetLabs.nl> wrote on 03/30/2009 02:00:55 PM:
> roy at nominet.org.uk wrote:
> >  Please discuss how we can circumvent this, as it is pretty
> > 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
> > 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.
> >  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.
> 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.
> >  Feature request idea: do we need to be able to generate keys in
> > Say with an option for -G to generate X keypairs ? Since we don't need
> > specify anything _per_key_ this seems feasible. This seems to fit the
> > 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 :)
> >  I understand from the world of cryptographers to avoid "3" as
> > exponent, as there might be implementations that are susceptible to
> > Bleichenbacher's RSA signature forgery scheme due to sloppy padding.
> > 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
> > exponent, solely to be able to identify which zones use OpenDNSSEC by
> > 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.
More information about the Opendnssec-develop