On Sat, 30 Mar 2019 at 21:36, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 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.
If you're trying to design some way to recover trust anchors after a key roll, might I suggest keeping it generalized to "trust anchors" and not "root zone trust anchors"? Someone suggested keeping a set of DNSKEYs with a chain of RRSIGs in an alternate zone, but that isn't scalable to multiple trust anchors unless you've also got some way to signal the name of the alternate zone at the apex. And then we're talking about adding a delegation to the root zone that is not a TLD registry, which has its own set of complexities. Not that whatever you're thinking was necessarily only applicable to the root zone, but I mention this in the hopes that people keep it in mind. If we want to try to add something like a chain of old keys signing each other, it probably needs to be at an off-apex special name (underscores! yay!) or use a new type that is DNSKEY-like, but for a special purpose.