This got stuck in my outbound queue for a few days. On Saturday, September 20, 2014, David Conrad <david.conrad@icann.org <mailto:david.conrad@icann.org>> wrote: Tomofumi, On Sep 19, 2014, at 11:46 AM, Tomofumi Okubo <tomofumi.okubo@gmail.com <javascript:;>> wrote: > The former is emergency roll and the latter is planned roll. > > The rollover we are discussing now falls under the latter. Actually, I don’t think we’ve started the discussion on changing the key as yet :). Is there a need to have a different set of policies/processes for an emergency roll vs. a planned roll? Is a planned roll a proper subset of an emergency roll? Yes and no. If you're using 5011 as the model, and you have two keys as trust anchors, and one associated private key is compromised, then there really isn't a lot of difference in proceedures. You revoke the compromised key, and start the process of getting a new key accepted as a trust anchor. The emergency thing shows up when all of your existing trust anchor keys are compromised. And there really isn't a way to deal with that contingency, planned or not. Basically, if A[public] is your only root trust anchor and A[private] is compromised, you're dead in the water. You can attempt to add new B[public] keys to the trust anchor set using 5011, but there's a good chance that your attacker is attempting to dothe same thing. If the attacker revokes A[public] by setting the bit and signing the root DNSKEY RRSet with that key, what probably happens is that ALL data without subordinate trust anchors is considered invalid by resolvers and rejected. 5011 gave very specific guidance on what needed to go into the root DNSKEY RRSet to avoid this case - but the current RRSet and Trust Anchor set are missing the second KSK. Mike Regards, -drc