[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