-----BEGIN PGP SIGNED MESSAGE-----
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.


Exactly.

>
>> 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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFEKBRpujy2e45Zk3URAncdAJ0Xn47JDZ6Ugz3LQd2pAA tK5A4aUQCfT2eb
5KTBlt+Ns8efWM5IRf/0AlE=
=widg
-----END PGP SIGNATURE-----

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