<font size=2 face="sans-serif">Have we implemented KSK rollovers yet?
</font>
<br>
<br><font size=2 face="sans-serif">For each zone, I imagine the process
to be:</font>
<br>
<br><font size=2 face="sans-serif">1. KASP calculates when the current
KSK should be rolled.  If within some interval (the "KSK Warning
interval", a parameter of the policy), it issues a warning that the
key will be rolled at the calculated time.  (This handles requirement
2.4.3.6 for warning about key rollovers.)</font>
<br>
<br><font size=2 face="sans-serif">2. When KASP is run at or after the
calculated time, it will (a) introduce a new KSK into the zone, (b) identify
a KSK (not the one just introduced) to be used for signing.  It will
also output a message stating that the DS record for the new key should
be installed in the parent zone.</font>
<br>
<br><font size=2 face="sans-serif">3. The signer, when run, will also generate
files containing the DS records for all KSKs and place them into a separate
directory.  The file names will be based on zone name and include
the identification that KASP has included in the message output in the
previous step.</font>
<br>
<br><font size=2 face="sans-serif">4. It is then up to the operator what
they do.  They can either (a) just pass the identified DS file to
the parent zone and ask it to be included or (b) pass all KSK files to
the parent zone, requesting that all current DS records be removed and
the DS records in the files be added.</font>
<br>
<br><font size=2 face="sans-serif">5. At some time after a KSK rollover,
the old KSK is removed from the zone (i.e. when KASP is next run, the KSK
will not be in the list of keys passed to the signer).  KASP will
output a message to the log file stating that the identified key can be
removed.  It is then up to the operator what they do - they can either
(a) request the parent zone to remove the DS record, or (b) wait until
the next KSK rollover when, if they follow the logic of step 4, option
b, it will be automatically removed.</font>
<br>
<br>
<br><font size=2 face="sans-serif">The questions I have are:</font>
<br>
<br><font size=2 face="sans-serif">a) Does KASP warn about a rollover?</font>
<br><font size=2 face="sans-serif">b) Does KASP notify the user when a
KSK rollover is happening? And does it identify the DS record(s) that should
be added to the parent zone?</font>
<br><font size=2 face="sans-serif">c) Does the signer create the DS record
in a way that it can be easily found?</font>
<br><font size=2 face="sans-serif">d) Does KASP notify the user when a
DS record should be removed from the parent zone? And how does it identify
the key to be removed?</font>
<br>
<br><font size=2 face="sans-serif">In the longer term, do we also want
to add the ability for OpenDNSSEC to check whether a DS record of a KSK
is in the parent zone before we actually start signing the zone with the
new key (as suggest in the KSK rollover algorithm in the key timing draft?)
 At present, I believe the assumption is that the DS record will appear
in the parent zone within some (configurable) interval of it be available
to the operator.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Stephen</font>