RE: DN->DNS mapping in draft-ietf-ldapext-locate-05.txt

["Paul Leach" <paulle@Exchange.Microsoft.com>]

> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu] 
> Sent: Monday, March 26, 2001 12:47 AM
> 
> But I have to think that the burden of proof goes the other 
> way.

That is not what experience says. Tony Hoare, Turing award winner: "you
know you're done when there's nothing left to throw out".


> What is the "sensible technical reason" for having the 
> mapping the way it is in -05?  Why is a mapping that imposes 
> more limitations on naming better than one that permits more 
> options, however unsightly they may seem to some? So far 
> there has been a lot of hand-wringing but not a single 
> substantive reason that I can see.

The current spec is a well defined function over a well defined range.
It was carefully crafted to not have unintended side effects, in
particular to not accidentally get in the way of other efforts to enable
locating servers given a DN.

The new proposal has several unexpected aspects that have been pointed
out here, as well as a security consideration that Kurt pointed out in
Minneapolis (insertion of a DC lower down in the hierarchy can have an
effect not expected by the user or the owners of higher levels in the
hierarchy -- it changes the chosen server).  As it turns out, when the
DN is that of a certificate, this doesn't matter, because if you go to
that server and look up the certificate, you can verify that the DN in
the certificate is the correct one. For ordinary LDAP data, that is not
the case. That's one reason that I believe the requested extension
should be written as a separate RFC, that explicitly states that it is
only for the purpose of locating a server that holds certs with the
given subject DN.

Paul