Subject: Re: Comments on delegation signer

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Jun 2002 19:15:46 +0200 (CEST)

I haven't seen any followup past this email.
Once I have an updated I-D with the editorial clarifications 
I can start the IETF last call.

  Erik

>----- Begin Included Message -----<

Date: Fri, 10 May 2002 08:17:43 -0400 (EDT)
From: "Ed Lewis" <[email-masked]>
Subject: Re: Comments on delegation signer
To: "Erik Nordmark" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

On Fri, 10 May 2002, Erik Nordmark wrote:
> The reason I assumed that saying "Secure delegations" here is because
> the paragraph in question start with the text 
>    For every secure delegation there MUST be a DS RRset stored in the
> 
> How should that whole paragraph be rewritten to capture the difference
> you point out?

In order for a delegation to appear to be signed, the parent zone MUST
contain a DS RR set for the child.  Whether or not the resolver making
the determination of security will decide that the child zone is secure
will start with the evaluation of a DS RR set, unless the resolver has
already configured a key for the child zone.

Delegation points MAY contain only the following RR sets: NS, DS, NXT,
and SIG.  Delegation points MUST not hold any other RR sets, implicitly
including KEY RR sets.  The NS RR set MUST NOT be signed by the parent
zone regardless of the security status of the delegation.  Note that
although the NXT RR set held in the parent and the set held in the
child will share the same owner name, class, and type, the two are
distinct sets and will have different values in their respective RDATA.

...this assumes that "delegation point" refers to the data in the parent
to identify a cut point.  I did make two pararaphs out of this to try and
provide more clarity.  I also rearranged the decription of the types held
to put what can be done first (+) and what can't be done second (-).
Finally, the original text explicitly mentions that the NXT's will differ
from parent to child, but then again, so will the SIG set, and possibly
the NS set....

> I don't think I said that tags aren't useful - I'm just confused by the
> values in the example.

I misunderstood the intent of your comment.

> My reading of the document was that the tag value is also useful for the
> resolver to more quickly find the key.
> My question is how this is done given the tag values in the example.

In looking a the example (section 3), it appears that the zone is "broken"
as the DS RR does not refer to a KEY RR.  The tag in the DS should be the
same as (one of) the tag(s) in the KEY RR set.  I think that's obvious -
IOW, the example is broken.

>----- End Included Message -----<

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>