Hash: SHA1

On Mar 27, 2006, at 9:59 AM, Olaf M. Kolkman wrote:

> On Mar 26, 2006, at 10:22 PM, David Blacka wrote:
>>> Rather than going into that detail, I propose that we choose the
>>> path of simplicity and eliminate the delegation-only requirement.

>> I'm not sure that is the simplest path. A seemingly great number
>> of questions about how opt-in works are essentially answered with
>> "that can't happen because it is delegation-only". Like, for
>> instance, can you opt out the zone apex (no) ? can you opt-out a
>> wildcard (no) ? So we would have to replace "delegations only"
>> with a possible more complex set of rules.

> Besides, the delegation only requirement the result of endless and
> heated debates about the change in the security model that we had
> when opt-in first came to the table.
> I prefer we do not try to relive that era.


>> I.e., by issuing a query for possible-delegation/IN/NS to the parent.

> Would querying for a DS at that parent work? I would think that
> that would be the regular fall back when trying to build a chain of
> trust?

Depends on what you mean by "work" I think you can certainly not
generate false validation failures, but it would be difficult to
enforce delegation-only.

Essentially, in order to enforce the MUST in section 4.2.1 of opt-in,
the validator MUST see the delegation in order to distinguish the
case from an non-delegation-only opt-in zone. The DS query to the
parent won't show that.

Personally, I think that using the DS query is fine, as I don't see
any actual security value from the validator actually enforcing
delegation-only in this case. However, it doesn't match what the
document says.


- --
David Blacka
Sr. Engineer VeriSign Applied Research

Version: GnuPG v1.2.4 (Darwin)

iD8DBQFEKBRpujy2e45Zk3URAncdAJ0Xn47JDZ6Ugz3LQd2pAA tK5A4aUQCfT2eb

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.