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

From: "Paul Leach" <[email-masked]>
Date: Wed, 28 Mar 2001 00:28:05 -0800

Here's my take.

The draft-locate-05 says how to find a server that store a given DN when
the DN conforms to the rules in RFC 2247.
An example of such a DN:
	cn=John Doe,ou=accounting,dc=example,dc=net

Certain other people want a way to find a server that stores a DN when
the DN does not conform to 2247, but to some looser set of rules. An
example of such a DN might be
	cn=John Doe,ou=accounting,dc=example,dc=net,o=example
corporation,c=us

As written, draft-locate-05 says NOTHING about such DNs. It simply does
not apply, because they do not conform to 2247. There is therefore
nothing that stops such people from writing a draft that says how to
find a server that stores such DNs, without in any way conflicting with
draft-locate-05.

Whereas, if we change draft-locate-05 to incorporate rules for such DNs,
we also have to get 2247 changed.

They should therefore write such a draft. Their draft should be easy --
it can say how certain DNs that do not conform to 2247 can be morphed
into ones that do (by moving all the "dc=" components to the right side,
keeping the ordering), and then applying the rules in draft-locate-05.

Paul

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 28 Mar 2001 00:42:43 -0800

> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:[email-masked]] 
> 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