Also see thread starting at: http://darkwing.uoregon.edu/~llynch/dnsop/msg03465.html
In a discussion between Olaf and Ed, Ed was the last to reply: > > >> > >> #3.3 Key Effectivity Period > >> > >> # For Key Signing Keys a reasonable key effectivity period is 13 > >> # months, with the intent to replace them after 12 months. An intended > >> # key effectivity period of a month is reasonable for Zone Signing > >> # Keys. > >> > >> Shouldn't this be linked to some minimum size of the key? > >> > > > > > >What about prepending a line to the above paragraph introducing a new > >one sentence paragraph directly after that: > > > >+ From a purely operational perspective a reasonable key effectivity > >+ period for Key Signing Keys is 13 months, with the intent to > > replace them after 12 months. An intended key effectivity period > > of a month is reasonable for Zone Signing Keys. > > > >+ For a key-size that matches these effectivity periods see section 3.5 > > > > Using these recommendations will lead to rollovers occurring > > frequently enough to become part of 'operational habits'; the > > procedure does not have to be reinvented every time a key is > > replaced. > > > > Key effectivity periods can be made very short, as in the order of a > > few minutes. But when replacing keys one has to take the > > considerations from Section 4.1 and Section 4.2 into account. > > I have two answers to this. > > One is that I think recommending a span of changes is good, and > saying that you should fit the key size to the span. (As opposed to > trying to worry about how long a key of a certain size will last.) > Operations can deal with the calendar better than less tangible > "events" (such as the time until a key is exposed or guessed). > > The other answer is that I have heard suggestions that the KSK ought > to be longer lived - like 3 or so years. For the root, because of > the pain of putting it into anchor positions, even longer. This is > counter to "keep it regular so you get used to it" but it has appeal > to non-operations people. > > I think it would be wise to recommend timing because there aren't a > lot of clear statements on this important issue. But perhaps you > need to recommend different time scales for different kinds of zone > administrations. > > Others? > Also see Bill Mannings reply: http://darkwing.uoregon.edu/~llynch/dnsop/msg03469.html I read Ed's first answer as concurring with the text. I read Ed's second answer as a request for more text. I wonder if that request still stands if we put this text back into section 3.3 and view it in its context. Section 3.1 starts with the some special remarks about the high level zones and trust anchor difficulties. I would like to propose to keep the text as is propose above (in the paragraphs with the "+" signs. But extend it with a reference to 3.1.2 (the ++ signs) + From a purely operational perspective a reasonable key effectivity + period for Key Signing Keys is 13 months, with the intent to replace them after 12 months. An intended key effectivity period of a month is reasonable for Zone Signing Keys. + For a key-size that matches these effectivity periods see section 3.5 Using these recommendations will lead to rollovers occurring frequently enough to become part of 'operational habits'; the procedure does not have to be reinvented every time a key is replaced. ++ As argued in 3.1.2 securely updating trust-anchors will be extremely ++ difficult. On the other hand the "operational habit" argument does ++ also apply to trust-anchor reconfiguration. If a short key-effectivity ++ period is used and the trust-anchor configuration has to be revisited ++ on a regular basis the odds that the configuration tends to be ++ forgotten is smaller. The tradeoff is against a system that is so dynamic ++ that administrators of the validating clients will not be able to ++ follow the modifications. Key effectivity periods can be made very short, as in the order of a few minutes. But when replacing keys one has to take the considerations from Section 4.1 and Section 4.2 into account. I am hesitant to come up with different time scales for different zone adminsistrators. I would also like to remind folk that this document is intended as guidance for "common domain operators". ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
