bert hubert wrote:
> On Mon, Dec 04, 2006 at 04:20:50PM -0500, David Blacka wrote:
>> I feel compelled to point out that NSEC3 isn't that complicated to
>> actually *do*. If it is complex, it is complex to analyze. That is, it
>> can be hard to convince yourself that it works without a bit of mental
>> stretching.

>
> It has a 51 page draft, and it details only *non*-existence.
>
> I am referring to NSEC3 non-existence proofs. Perhaps I missed something,
> but messages like:
>
> "In practice, then, we must show an NSEC3 record that encloses the hash of
> x.C, one that encloses the hash of *.C, and any RR owned by C (which could
> be an NSEC3, in which case it would be owned by the hash of C). A resolver
> verifying this proof would have to try longer and longer closest enclosers
> to determine which was being demonstrated as C, if an NSEC3 is presented.
> If any other RR was used, then C would be the owner. Once C has been
> determined, the resolver can easily check x.C and *.C against the proof."
>
> http://www.ops.ietf.org/lists/namedr.../msg00468.html
>
> .. look rather like I need to solve for a system of constraints within my
> software.
>
> But perhaps this applied to a previous draft, of perhaps I am dense (most
> likely). The mind boggles however at the failure modes implied by the
> wording quoted above.


I don't see why. All its saying, admittedly at great length, is that you
have to determine the closest encloser.

--
http://www.apache-ssl.org/ben.html http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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