[ksk-rollover] alternatives to 5110 for automating roll-over

Matthew Pounsett matt at conundrum.com
Sun Mar 31 22:01:44 UTC 2019

On Sat, 30 Mar 2019 at 21:36, Michael Richardson <mcr+ietf at sandelman.ca>

>     > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190331/3aae1e02/attachment.html>

More information about the ksk-rollover mailing list