Re: [dnsext] [dane] Aiming towards some specific wording

[Mohan Parthasarathy <[e-mail]>]

On Tue, Nov 22, 2011 at 5:55 AM, Edward Lewis <[e-mail]> wrote:
> (Took DANE off because I'm not on the list.)
>
> At 20:10 -0800 11/21/11, Matt McCutchen wrote:
>
>>That's great, RFC 4035 has a totally different definition of
>>"indeterminate" than RFC 4033.
>
> You're right.  When I answered I went to 4035 because it is the "protocol
> mod" and not 4034 because it was "records".  I usually ignore 4033 because
> it's "intro" and has no requirements language in it.  That's just to explain
> why I quoted 4035 (because these kind of terminology things run rampant in
> RFCs) and why I didn't quote 4033.
>
> Not that 4033 is any less wrong than 4035.  I just ordinarily look at
> 4034/4035 more.
>
> Here's what '33 says:
>
> #   Indeterminate: There is no trust anchor that would indicate that a
> #   specific portion of the tree is secure.  This is the default
> #   operation mode.
>
> Certainly different from 4035 and what I would assume was the right way to
> define indeterminate.
>

This is an old thread but may be relevant now. As we are in the last
call of dnssec-bis updates, we should clarify this.

Even the definition of Insecure is different. 4033 says that you have
the signed proof of the non-existence of a DS record where as 4035
says you declare insecure if you can't construct the chain which could
be because of the missing DNSKEY/DS RRs. I may not  be able to obtain
them because of the bad CPE device. Can it not be Bogus as per the
definition in 4035 ?

If the application is going to be sensitive and react differently
based on these status codes, then this should either be simplified or
clarified in the dnssec-bis updates.

-mohan

> --
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis
> NeuStar                    You can leave a voice message at [phone]
>
> Vote for the word of the day:
> "Papa"razzi - father that constantly takes photos of the baby
> Corpureaucracy - The institution of corporate "red tape"
>
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext