<tt><font size=2>Jakob Schlyter <jakob@kirei.se> wrote on 02/07/2009
19:26:27:<br>
<br>
>> On 2 jul 2009, at 13.39, Stephen.Morris@nominet.org.uk wrote:<br>
> <br>
> > a) Does KASP warn about a rollover?<br>
> <br>
> I believe we should warn via syslog.</font></tt>
<br>
<br><tt><font size=2>That will be fine, I asked the question just to ensure
that this is done.</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>> > b) Does KASP notify the user when a KSK
rollover is happening?<br>
> <br>
> I believe we should warn via syslog here as well.</font></tt>
<br>
<br><tt><font size=2>Again, that is OK.</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>> > And does it identify the DS record(s) that
should be added to the  <br>
> > parent zone?<br>
> <br>
> it might be nice to log the keytag of the new KSK(s).<br>
> <br>
> > c) Does the signer create the DS record in a way that it can
be  <br>
> > easily found?<br>
> <br>
> at the last meeting in Amsterdam we decided that the signer should
not  <br>
> save the DS records in any file - the user can use drill or similar
to  <br>
> get data needed to send to the parent.</font></tt>
<br>
<br><tt><font size=2>The DS record was my first thought.  Reading
RFC 4310, I see that to create a DS record, EPP requires:</font></tt>
<br>
<br><tt><font size=2>key tag</font></tt>
<br><tt><font size=2>algorithm</font></tt>
<br><tt><font size=2>digest type</font></tt>
<br><tt><font size=2>digest</font></tt>
<br><tt><font size=2>optional max sig lifetime</font></tt>
<br><tt><font size=2>optional keydata</font></tt>
<br>
<br><tt><font size=2>It is certainly not OpenDNSSEC's place to interface
to EPP, but it is its responsibility to make the information easily available.
 Asking the user to use a tool like "drill" feels like a
step too far, although it is acceptable for the technology preview.  Instead,
could KASP or the signer log the information in syslog? If this is in the
form of an easily identifiable message, the user's systems could intercept
those messages and automatically generate an EPP request to the parent.
 (Which leads to a definition question: should it be KASP or should
it be the signer that generates the message?)</font></tt>
<br>
<br><tt><font size=2><br>
<br>
> > d) Does KASP notify the user when a DS record should be removed
from  <br>
> > the parent zone? And how does it identify the key to be removed?<br>
> <br>
> as soon as the new KSK gone active and all signatures been  <br>
> regenerated, it could log this as well?</font></tt>
<br>
<br><tt><font size=2>If it logs when a DS record (presumably identified
by key tag) should be removed from the parent, the user's systems could
intercept the message and issue the appropriate EPP update command.</font></tt>
<br>
<br>
<br><tt><font size=2><br>
> > In the longer term, do we also want to add the ability for  <br>
> > OpenDNSSEC to check whether a DS record of a KSK is in the parent
 <br>
> > zone before we actually start signing the zone with the new key
(as  <br>
> > suggest in the KSK rollover algorithm in the key timing draft?)
 At  <br>
> > present, I believe the assumption is that the DS record will
appear  <br>
> > in the parent zone within some (configurable) interval of it
be  <br>
> > available to the operator.<br>
> <br>
> right.<br>
> <br>
>    jakob<br>
> <br>
</font></tt>
<br><tt><font size=2>Stephen</font></tt>