Subject: keysets at the registry

From: Miek Gieben <[email-masked]>
Date: Mon, 23 Oct 2000 14:06:42 +0200

hi,

Were having the following problem.

I'm playing a registry, and for now i have 1 child: nlnetlabs.nl.nl.

The child want to be secure, so it sends a keyset to me.
That keyset contains the public key and a sig with
an expiration and inception time.

Now it is time for the registry to sign the key of nlnetlabs.nl.nl.
So i give the following command:
/nlnl/sbin/dnssec-signkey nlnetlabs.nl.nl.keyset ../Knl.nl.+001+26773.private 

This results in nlnetlabs.nl.nl.signedkey with the _same_ 
expiration and inception time as the original keyset.

When this sigs expires and the registry wants to resign the keyset, it
must get a new keyset from the child.

Is this really necessary? Why not only send a key to the registry?

grtz Miek
NLnet Labs

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Oct 2000 09:56:17 -0400

>Is this really necessary? Why not only send a key to the registry?

1) The SIG accompanies the KEY as a convenient means to express the
validity period.  The $TTL directive is a convenient means to express the
desired TTL.

dnssec-keygen output writes out the key record, missing two important
pieces of information.  One is the TTL, the other is the validity period.
The reason dnssec-keygen omits thee TTL is that the TTL is a facet of the
zone and will be set when the zone is signed/otherwise processed.  The
validity period is ommitted because that is set at signing time, not key
generation.  (The KEY doesn't expire, the SIG does.)

In BIND 8, this was "solved" by the .PARENT file.  This solution was not
satisfactory however - other problems ensued.

So, in BIND 9, the need to add the TTL and validity period to the KEY when
it being sent to the parent for validation remained and was met by using
existing structures.

2) When the parent gets the keyset file and verifies that the file came
from the authorized sender, the parent can also verify that the key(s)
arriving are the correct keys, i.e., no one has changed them.  The sender,
by having a copy of the .keyset file, can use that and the .signedkey file
to verify that no one added or deleted a key.  (Such a tool has not been
written yet.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

---

From: Brian Wellington <[email-masked]>
Date: Mon, 23 Oct 2000 08:41:38 -0700 (PDT)

> expiration and inception time as the original keyset.

This is an omission in dnssec-signkey.  It will be in a later version,
probably bind 9.1.  The plan was to have the child specify a validity
period that it desired, but this could be overridden by the parent.

> Is this really necessary? Why not only send a key to the registry?

Several reasons.  As Ed mentioned, the TTL needs to be included.  
Including a hint as to the validity period is also useful.  Also,
dnssec-signkey can attempt to verify the SIG records, which shows that the
creator of the key set possessed the private keys associated with the
public keys in the file.

Brian

---

From: Miek Gieben <[email-masked]>
Date: Tue, 24 Oct 2000 11:10:36 +0200

> period that it desired, but this could be overridden by the parent.

okay great! Where can i get it? :-)

grtz Miek

---

From: Brian Wellington <[email-masked]>
Date: Tue, 24 Oct 2000 10:27:29 -0700 (PDT)

> okay great! Where can i get it? :-)

The plan is to have a 9.1 beta out sometime early in November.  That's
only a few weeks away...

Brian