[Opendnssec-develop] Creating keys

Roy Arends 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:

> Hello,
> > >>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.

Roy Arends
Sr. Researcher
Nominet UK

More information about the Opendnssec-develop mailing list