[Opendnssec-develop] Creating keys

[Rick van Rein]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 control"
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).

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 the
case when we are looking at nlnetlabs.nl, surfnet.nl and openfortress.nl.
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 choose
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 should
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, which
would call for multiple keys on one OpenDNSSEC deployment.  However, I've
been wondering when this would happen, and found only a somewhat contrived
example.  A hoster (like SURFnet) could be willing to sign DNSSEC domains
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 them.
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


Cheers,

Rick van Rein
OpenFortress Digital signatures
http://openfortress.nl/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html

iD8DBQFJNS+8FBGpwol1RgYRApnpAJ9DDhccF8lgYKXY7Ny7gvzkehIUJwCcCr1e
53L+Awjo1GOieYFFf3edO8c=
=iVIJ
-----END PGP SIGNATURE-----