Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-02.txt

[Brian Wellington <[e-mail]>]

On Thu, 12 Jul 2001, Edward Lewis wrote:

> Ref. section 2, the term "Authenticated" is used.  I think you mean to say
> that the data has been verified via a temporally and cryptographically
> verified chain of trust back to a configured key.  Authenticated is too
> broad a term, so you need to qualify it in this context or redefine it.
> Even if this is done in another document, you should reference that more
> explicitly.

Authenticated is defined is RFC 2535, section 6.1.  There's a reference to
that right above the first use.

> Now, for a open question.  Authenitcated data presumably means that the
> chain was built according to some policy - e.g., RFC 300x.  What will
> happen when the authenticating server uses a policy that is not strong
> enough for the resolver?  Will there be a way to indicate the policy used?
> (This is also a question to folks wanting to research off-tree validation.)

The resolver should only be looking at the AD bit if it trusts the server.
Any resolver that has a policy should be doing the validation itself.

> Finally - should it be more explicit that data in the additional section is
> not (never) checked?

I think it's explicit enough.  There are only 4 sections - it's not hard
to figure out which one isn't referred to :)

> Is there a reason to always omit signatures from the
> additional section in this case?  (Why provide them if they've been
> ignored?)

Signatures in the additional section and the AD bit are orthogonal, I
think.  Only stub resolvers should care about the AD bit, and stub
resolvers shouldn't use the additional section at all.

Brian



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.