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. Yes, there is some non-trivial cost for the root-zone key holder to keep more private keys safe. It is my understanding that the ICANN software for this is being revised to be significantly more flexible, and so I also see this as a way to make sure it all really works. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-