[ksk-rollover] [Ext] Re: Starting discussion on acceptable criteria for proceeding with the root KSK roll

[David Conrad]

Mike,

On January 7, 2018 at 12:53:15 PM, Michael StJohns (msj at nthpermutation.com<mailto:msj at nthpermutation.com>) wrote:
> If they key gets lost or compromised, my understanding is that we cannot use RFC 5011 to do the roll and must fall back to doing an out-of-band key rollover. We aren’t really exercising this under this iteration of the community defined KSK rollover plan.

Um.  No.

As currently operationally practiced, I believe my statement is correct.

In fact, at this point you’re closer to being able to use 5011 as I designed it than ever before.  I.e., you have two trust Anchors.

And to state the obvious, the reason we’ve postponed the KSK rollover is indications that some resolvers are only configured for one trust anchor.

 If you want to be able to support key compromise and emergency replacement the next step is to add anchor C .  The step after that is to revoke the current (old/original) trust anchorA.  Keep C’s private key off line and in threshold pieces.    Sign the DNSKEY RRSet with B.

This may be an opportunity to revise operational practice. Providing this as input may be worthwhile.

Regards,

-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180109/3846d61d/attachment.html>