Tony Finch <
dot@dotat.at> wrote:
Fred Baker <fred@isc.org> wrote:
The key consideration is that key rollovers are a "usual" event, and as
such the key(s) should be something learned from the root and the root
servers, not something configured or compiled into the resolver
software.
+1
I agree that rollovers need to be routine (I think annual makes sense) but
they have to be planned with software releases in mind. This might require
keys to be generated and promulgated out of band a long time before they
are published in the zone or used for signing. Then a vendor package can
include root keys covering the next couple of years, say.
I think that there is very little incremental cost to including a multitude
of keys in a software release. i.e. rather than 1 or 3 for the next 3-4
years, I'd like to around a dozen. With a variety of algorithms, keysizes,
and with the private keys escrowed in a variety of ways. Some will be
expired without ever been used... they are just in case, or in support of
as-yet-unknown contingencies. (including fire-drills for such switches)
I'd like for this to include a hash-based signature system, but I'm not sure
we have the standards specifications for this nailed down sufficiently.