To:
"Olaf M. Kolkman" <olaf@ripe.net>, "Bill Manning" <bmanning@isi.edu>
Cc:
<dnssec@cafax.se>
From:
"Scott Rose" <scottr@antd.nist.gov>
Date:
Thu, 10 Oct 2002 12:50:43 -0400
Sender:
owner-dnssec@cafax.se
Subject:
Re: root zone signing and key lengths/lifetimes
Okay. Seeing that there is no revocation list in DNS, I can understand the desire for frequent zone key rollover. Key signing keys (at the root) are going to need a special process to distribute, so regular rollover/emergancy rollover kind of means the same thing. That is, there is no parent to interact with, but static resolvers. Mainly I was wondering why the draft set up frequency of key rollovers. Not that it's a huge technical problem. Although the human nature side of me is reminded that the more frequent the operation, the more frequent human error creeps in. Scott ----- Original Message ----- From: "Olaf M. Kolkman" <olaf@ripe.net> To: "Bill Manning" <bmanning@isi.edu> Cc: <scottr@antd.nist.gov>; <dnssec@cafax.se> Sent: Thursday, October 10, 2002 9:27 AM Subject: Re: root zone signing and key lengths/lifetimes > > > we are using a key signing key with a validity period of 12 months > > and zone signing keys of 30 days in the testbed. > > > I hope that the signing validity periods will be made smaller by at > least a factor 3-4. > > The signing validity period is an indication for how long a > (compromised) key remains useful. A stronger key may not be > compromised by crypto analysis but may still be compromised. > > A key which is not often rolled over can still be used to generate > signatures with short validity interval's. > > In the above scheme, if a root zonesigning key, would be compromised > it would be usable for the bad guys for a maximum of 12 months. > > If one of the TLD's keys would be compromised that 'situation' could > persist for a maximum of 30 days. > > I wonder if 3 months for key and a week for zone signing signature > validity intervals would be feasible for the root. > > > --Olaf > > --------------------------------------------| Olaf M. Kolkman > | www.ripe.net/disi