[Opendnssec-develop] Creating keys
roy at nominet.org.uk
Tue Dec 2 13:11:51 UTC 2008
Rick van Rein wrote on 12/02/2008 01:53:21 PM:
> > >>And again, here I can see a many zones using one private key. [...]
> > >>
> > >If you share keys do you need to coordinate key roll overs? [...]
> > >
> > Yes, all zones that share the same private key will need to roll at
> > the same time.
> Sharing of key pairs makes bundles of sense to me.
> Using PKCS #11 as a generic HSM interface, will give rise to deployment
> models that use simple USB tokens as a low-cost keystore. This could be
> used by owners of a few zones, such as the administrator of a company's
> single/few domains. I suspect many companies will want to be "in
> of their "vital square on the net", based on such a thrifty setup.
> USB tokens cannot store very many key pairs, think of 10 to get an idea.
> It could become a nuisance to be constrained in the number of zones one
> manages if the token cannot cope, and it will at some point cause a new
> domain number 11 to remain unsigned "for now", however long that lasts.
> Being able to share key pairs among zones would be totally reasonable in
> such situations, in my opinion.
> This is not even counting the fact that we would like to have some room
> to move in a token, for overlapping key validity periods. It would be
> dead wrong to have to deny a KSK rollover to a signer using a USB-token
> for reasons like a slow parent DS pickup on a previous one. Or worse,
> to be unable to rollover in case of compromise. We'll need the space
> for a variable few KSK at the same time in such a token, and that is
> enough demand to roughly fill up an average one.
> But do we believe OpenDNSSEC should be the solution for such
> few-domain admins? Or should they be redirected to a tool like
> Holger's ZKT, which does well for smaller roll-out scenarios?
> I think the dynamic-signer properties and use of PKCS #11 can
> make OpenDNSSEC useful in places where ZKT is not active (yet).
OpenDNSSEC should be _the_ solution for such few-domain admins. The
mandate that we have is that OpenDNSSEC should be the common tool for
managing signed domains. If you have one domain, and want it signed, use
Fwiw I do not see a market for USB tokens as a keystore in this sense. USB
tokens tend to get lost, stolen, or left connected to a device (or left in
a bar or taxi, if you work for British Government). Note that data needs
to be signed periodically and regularly. If you have a high value domain,
use a proper fips-140-2 level 4 HSM. If you have huge number of highly
volatile domains, use an HSM that is specifically build for acceleration.
I think it is fine, in the general case, to have a softtoken.
> The next question then, is when key pairs could be shared? Since a key
> coincides with responsibility to manage it, I suppose most deployments
> would stipulate that key pairs SHOULD at most be shared among zones
> administered by the same party. As is the case with the example of the
> admin before. As is the case with .co.uk and .org.uk. But as is not
> case when we are looking at nlnetlabs.nl, surfnet.nl and
> The latter three MUST NOT share a key pair.
> > For a KSK rollover that is most tricky since you have
> > to wait until all DS RRs at the parents are replaced, and then wait a
> > little more, but I do not think that is not doable.
> I also think it is doable. It is very likely that there will be a sort
> of service level agreement about DS update times, because without that
> it is impossible to predict when to start rolling over. (We could
> the times in RFC 4641, but it would be a matter of faith that the parent
> would adhere to it as well.) Taking the worst-case DS update time
> suffice to predict the key rollover preparation time.
> > >>Not that one priv-key to many zones excludes many-to-many.
> I do not think it is prudent to share keys among different parties,
> would call for multiple keys on one OpenDNSSEC deployment. However,
> been wondering when this would happen, and found only a somewhat
> example. A hoster (like SURFnet) could be willing to sign DNSSEC
> in an HSM for its constituents/customers. There are probably legal
> considerations that make it necessary to have different keys for each
> customer/constituent, and enable local backup procedures by each of
> In such cases, it would be required to support different key pairs.
> In summary, I believe
> * that USB tokens make it necessary to share key pairs among zones
> * that provider-signing makes it necessary to support multiple key pairs
I see no issue with using a key for multiple domains. I see no issue with
using a key per domain. Both policies can be implemented.
Note though that I do not believe that USB tokens make it nec'cy to share
key pairs among zones. See my earlier point.
More information about the Opendnssec-develop