Michael StJohns <msj@nthpermutation.com> wrote: >> list-ksk-rollover@dragon.net: >>> Phased rollout and control of when things change. >> Aye. >> I agree that we shouldn't prescribe how people automate, or even that >> they do it at all. 5011 is _one_ way to do it, and I happen to like >> it, but that doesn't mean that it is good for $everybody. mcr> In particular, it fails when the device is not on/connected during mcr> the period that the 5011 adds the new key, then it can not use 5011. > No - that's not correct. It fails if it wasn't able to see the old key > signing the new key for the add hold down period. If you're following > my recommendations in 5011, then the new key C is going to be signed by > A for a while, then B for a while, before it becomes the active key. Right. But, if the resolver has A as the trust anchor, and it's offline for the entire B-hold-down-period, then it never moves to B, and therefore does not trust B's signature on C. mcr> As far as I understand 5011, the only reason we can't leave the mcr> entire chain of keys in at the trust point is because the RRset would mcr> get unreasonably large, causing other failures. msj> No. *If* we can leave all the signatures in place, then we can use 5011 to roll forward? > Someone banned the use of the term "blockchain" in the discussion, but > something like that is probably the right approach. If by blockchain, you mean a merkle tree, then I agree... Perhaps the right answer is to sign the RSA/ECDSA/EDDSA keys with a hash-based signature scheme, which, while large, could be kept in a place that has enough space for such a thing. Would it have to reside, in a place reachable by numeric IP address only? I'm not sure. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [