Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

Olaf Kolkman <OKolkman@ripe.net> Mon, 09 April 2001 15:28 UTC

Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09303 for <dnsext-archive@lists.ietf.org>; Mon, 9 Apr 2001 11:28:04 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mdLC-000PQl-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 08:12:30 -0700
Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mdLC-000PPu-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 08:12:30 -0700
Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f39F3Qo05196 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 11:03:26 -0400 (EDT)
Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.16 #1) id 14mdH1-000PJ5-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 08:08:12 -0700
Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA20655; Mon, 9 Apr 2001 17:07:39 +0200 (CEST)
Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x50.ripe.net (8.8.8/8.8.5) with ESMTP id RAA14574; Mon, 9 Apr 2001 17:07:39 +0200 (CEST)
Message-Id: <200104091507.RAA14574@x50.ripe.net>
To: Edward Lewis <lewis@tislabs.com>
cc: Miek Gieben <miekg@open.nlnetlabs.nl>, Dan Massey <masseyd@isi.edu>, namedroppers@ops.ietf.org
Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)
In-reply-to: Your message of Fri, 06 Apr 2001 20:05:42 EDT. <v03130303b6f4081499b4@[192.94.214.136]>
References: <v03130303b6f4081499b4@[192.94.214.136]>
From: Olaf Kolkman <OKolkman@ripe.net>
X-Organization: RIPE Network Coordination Centre
X-Phone: +31 20 535 4444
X-Fax: +31 20 535 4445
Date: Mon, 09 Apr 2001 17:07:39 +0200
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk



Edward Lewis <lewis@tislabs.com> responding to Miek:

 * >We are not sure how or why you come to this conclusion from section
 * >4. The idea was, and still is, to have a short  transition period
 * >where both the old and new key are active.
 * 
 * One of the smokdering debates is why there is the need for roll over.  On
 * the one hand, old SIGs might still be fine if the old key is around.  On
 * the other hand, isn't the fact that a new key is available mean you should
 * forget the old data?
 * 
 * Now, the desire to use the old key to sign the new key set is the first
 * requirement I have heard that justifies the continued use of the old key
 * once the new key is present.
 * 

FYI:

The scheme I posted on Friday drops the requirement to have the old
KEY around. Actually it requires the old key NOT to be around. (If you
would keep the key in the keyset, and the parent would not keep state,
you might be able to trigger keyrollovers by spoofed notifies.)

"Isn't the fact that a new key is available mean you should forget the
old data?" seems to be an important question to answer...


--Olaf


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.