[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: <dnssec@cafax.se>, "Edward Lewis" <lewis@tislabs.com>
From: "Matt Larson" <mlarson@verisign.com>
Date: Fri, 22 Mar 2002 15:27:44 -0500
Reply-To: "Matt Larson" <mlarson@verisign.com>
Sender: owner-dnssec@cafax.se
Subject: Re: Keys and DS

> First question.  Is there a requirement/need to have a child provide
> authentication during the sending of material key material to the parent?
> (By "key material" I am not inferring a KEY set for this question.)

I agree with Dan's response: a parent must perform some authenticatation.  I
think not authenticating is untenable.  FWIW, I foresee authentication for
DNSSEC-related changes for com/net/org subzones using the same mechanism as
other domain modifications today: VGRS authenticates registrars, who are
only able to modify domains that they own.  In other words, we rely on
registrars to authenticate individual registrants, since (among other
reasons) we don't have any registrant information.

> Second question.  Should the child be responsible for sending the
generated
> DS records to the parent?  (This is perhaps a touchy question.)  I won't
> elaborate further, I would like to hear opinions.

We like the idea of submitting a self-signed key and letting the parent
compute the DS record: at least at one point the child possessed the
corresponding private key to generate the sig.  This method is espoused in
the DNSSEC EPP draft written by Scott Hollenbeck
(draft-hollenbeck-epp-secdns-00.txt).

> Third question.  With the use of DS, if each member of a zone's apex
keyset
> is represented by a (signed) DS record at the parent, is/are SIG(KEY)s
> necessary?  E.g., If I see this:
> [...]
> Is there a need for a SIG(KEY)?

As Rip has already pointed out, this would obviate what I understand to be
one of the key benefits of DS: having one key with a longer lifespan signing
a zone's KEY RRset, which could have other more-frequently changing keys to
sign the rest of the zone.  I also agree with Dan's point that exceptions
should be avoided.

Matt



Home | Date list | Subject list