[ksk-change] Testing new keys added
Michael StJohns
msj at nthpermutation.com
Fri Oct 10 16:49:04 UTC 2014
On 10/10/2014 2:05 AM, Jakob Schlyter wrote:
> On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>
>> Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root.
> No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/
Not exactly. By convention we split ZSK and KSK duties, but that's not
actually enforced by the resolver.
So
1. A and B sign (A B Z)
2. Z signs most of the zone.
3. B signs the DS record for the test zone.
Should work. But that doesn't prove anything about B's "trust
anchor"ness because the chain can go A -> (A B Z) -> B(DS) rather than B
-> (A B Z) -> B(DS).
If I'd been smarter, I would have provided a convention to query a
caching validating resolver for its trust anchors.
Mike
>
> jakob
>
> _______________________________________________
> 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/20141010/023cefcf/attachment.html>
More information about the ksk-rollover
mailing list