As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has 
the open issues listed and a per issue highlight of their history.

This issue is captured in  
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
current content of that page is replicated below.

I welcome substantive discussion on-list while I'd be happy to receive 
editorial comments off-list 

If the chair believes the current text captures consensus I will move this 
issue to the closed issues list.

--Olaf


$Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $
2008090101
   ZSK-roll-frequency
   EKR/ Paul Hoffman
   Added: 7 Oct 2009
   
See:
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html


Rfc4641 argues for frequent ZSK rollovers, the argument therein is
based on operational arguments that are (implicitly) based on operator
acces to private keys and/or the timeline in which changes in which
the (zone) operator may need to be replaced.

EKRs argument is based on cryptographic strength and argues another view.

The current considerations need to be made more explicit.

Resolution:


Added the following paragraph to section 3.3:

        <t>
          The motivation for having the ZSK's effectivity period
          shorter than the KSK's effectivity period is rooted in the
          operational consideration that it is more likely that
          operators have more frequent read access to the ZSK than to
          the KSK. If ZSK's are maintained on cryptographic Hardware
          Security Modules (HSM) than the motivation to have different
          key effectivity periods is weakend.

        </t>

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to