I think it is very important that it is possible to reliably update the DNS root trust anchor, so that key size changes and algorithm updates work, and so that it we can recover from a compromise (though I really hope that never happens!). 1. Prerequisites. There are still some gaps in the tools that support root key rollovers. I hope ICANN will encourage vendors to make improvements. Validators should provide tools to report their trust anchor RFC 5011 status. For example, I wrote a script check5011 which will be included with BIND 9.10. This is necessary so that the rollover process can be monitored, so that hostmasters can be sure the new key is trusted before the old key is removed. If something goes wrong it might be desirable to provide a tool that can force the RFC 5011 state of a trust anchor, rather than doing a full out-of-band reinitialization. Validators should be able to automatically update their trust anchor out-of-band, if they have missed the in-band RFC 5011 process. This includes software that ships with embedded copies of the current root trust anchor: it should be possible to install the software after a rollover without going through a complicated and intimidating manual process to fetch the new trust anchor. The update tools should handle restarts as well as initial installs, so that (for example) a virtual machine image created before a rollover will still work after the rollover. The unbound-anchor tool is a good example of what is needed. http://www.unbound.net/documentation/unbound-anchor.html Windows has a command `dnscmd /RetrieveRootTrustAnchors` but it is not clear if this handles restarts as well as initial configuration. BIND ships with an embedded copy of the root trust anchor. This needs to be replaced by a tool like unbound-anchor. 2. First rollover. Ideally this should have happened soon after the initial deployment of the root KSK and regularly thereafter. A pity. It would be good to have the better tooling widely deployed before the rollover. The rollover schedule in the DNSSEC practice statement for the root zone KSK operator is quite aggressive, taking two months. It might be worth doing a slower rollover to allow time for hostmasters to verify that RFC 5011 is working correctly, and to perform any fixes that may be necessary, such as software updates. The more thorough testing process proposed by Michael StJohns is a very good idea. 4. Rollover frequency. I think rollovers should occur annually. I don't think there is much advantage to an initial high frequency of rollovers followed by a slower regular schedule: that would conflict with a slower-than-usual first rollover. Annual rollovers are probably frequent enough to provide a useful learning experience. The rollover frequency should be high enough to ensure that vendors need to have proper implementations of in-band RFC 5011 and out-of-band trust anchor update tools. 5. Rollover calendar. Root KSK rollovers should have a regular schedule that is expected to continue indefinitely, like the root ZSK rollover schedule. If the schedule is changed then notice should normally be given in advance - a year before, perhaps? But this has to be on the understanding that emergency changes may be required. 6. Public notifications. Would it be worth using a CERT advisory to notify hostmasters that the KSK is to be rolled? This sould include helpful instructions for how to verify that automatic RFC 5011 updates are working, what to do in case RFC 5011 does not work, and which situations are likely to cause problems for RFC 5011 (such as offline machines, old software, etc.) 7. Other considerations. At the moment the out-of-band update mechanism is vulnerable to compromise of the ICANN signing keys which are used to make the OpenPGP and S/MIME signatures. The S/MIME signature is also vulnerable to compromise of any PKIX certification authority. It would be useful to have a small list of certification authorities that can be used to validate the S/MIME signature and the TLS connection to the root trust anchor publication web site. This would reduce the exposure to the PKIX certification authority system. It would be nice to know more about how the signing keys are managed: their storage and update schedule. Shouldn't there be a document like a DPS for these keys? I understand that ICANN would like to include third party signatures on the root trust anchor publication web site. This would be a very good thing, since it would allow out-of-band update software to require a quorum of valid signatures instead of just one. This improves security, since compromise of a single key does not compromise the whole process. It improves robustness, since signing keys will be able to change without breaking existing software that uses those keys for validation, so long as a quorum of old-enough keys remain in use.