[ksk-rollover] Revoking KSK-2010 imminent

[StJohns, Michael]

I haven’t been paying attention.  Is anything being signed by ksk2010
anymore?  If not, then revoking it should be the very definition of a
non-event.

And you can’t “delay the revoking “ once you’ve published the revoked key.
Revocations take place immediately upon receipt.  You could delete the
revocation from future publications, but I’d guess that if you wait more
than 1ttl after first publication such deletion would have little effect on
the overall system.

Lastly, existing systems should currently be trusting both 2017 and 2010 -
unless manually intervened - so why would systems show only 2017 trust?

Mike

On Sun, Jan 6, 2019 at 12:15 Chris Thompson <cet1 at cam.ac.uk> wrote:

> With the revoking of KSK-2010 in the root DNSKEY RRset due in 5 days time,
> is no one at all nervous about possible consequences?
>
> A couple of more specific question:
>
> 1. This has been asked before, but is anyone analysing the RFC 8145 data
>    to see how many servers are reporting that they only trust KSK-2017,
>    and are they in a position to track how this changes during the revoking
>    process? The graphs at
> http://root-trust-anchor-reports.research.icann.org/
>    are described in terms of servers trusting only KSK-2010 vs. all others.
>
> 2. In the unlikely event that publishing a revoked KSK-2010 causes
> significant
>    problems (e.g. the new high water mark for the size of a signed DNSKEY
>    response has been mentioned), do ICANN have a back-off strategy (e.g. to
>    delay the revoking)?
>
> --
> Chris Thompson
> Email: cet1 at cam.ac.uk
>
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190106/f9a67aba/attachment.html>