Like all good security discussions, things inevitably come back to the question about what are the threats one is trying to mitigate. Probably it's in a document that I didn't adequately read at some point, but given that we are having the discussion about why we should roll at all, it seems that we don't have a share understanding of the threats. As Fred says later in this thread:
From my perspective, we need the rolls in order to counter potential compromises of the root key. One of the characteristics of a successful compromise of the root key is that we don't know it happened. Hence, waiting until we know it happened to roll it is a matter of waiting for the horses to leave the proverbial barn before closing the barn door. Apologies if that's an Americanism...
If I understand the key signing ceremony proceedure correctly, there are multiple HSMs kept in multiple locations, but that each HSM has the same contents. We have many for redundancy/failure of HSM, not to split up the risk. It seems that having different iteration of the keys stored in different HSMs under control of different entities would help with dealing with the barn door being open. ==== {Personally, I still go back to: https://www.ssh.com/a/draft-ylonen-spki-binary-00.txt section 7.3.1: which was not AFAIK, published as an RFC: 7.3.1. One Possible Organization of DNS Name Delegation There is no single key for the domain name hierarchy. Instead, there are four keys, three of which are required to sign each top-level domain. The keys are each held by a trusted organization in the US, in EU, in Japan, and by some other suitable organization. ...} -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-