Subject: LDAP server location and DN->DNS mapping

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 11 Dec 2000 10:12:31 -0800 (PST)

draft-ietf-ldapext-locate-04.txt specifies how to use DNS SRV records to
find an LDAP DS given a DN that has DC components.  This has been mostly
uncontroversial except for some procedural things (whether to include
CLDAP, etc).  It has gone thru WG last call but not yet thru IETF last
call (still waiting on a couple of nits).  However, I'd like to raise a
fundamental question about how this scheme works, since it was recently
raised to me while discussing this doc with an IESG member, who said he
didn't like it the way it is and guaranteed to raise the issue during IETF
last call.

Section 3 of the draft defines an algorithm for mapping DNs into domain
names, for purposes of using those domain names for SRV record lookups.
This algorithm says that only DNs whose most significant components are
DC= can be mapped, that is,

   cn=John Doe,ou=accounting,dc=example,dc=net

maps to

   example.net

but

   cn=John Doe,ou=accounting,dc=example,dc=net,o=Example Corp,c=us

does not map to any domain name; therefore no use of SRV records to find
an LDAP DS is defined for such a DN.

The question on the table is:  why does the proposed mapping exclude DNs
of the second form above?  The mapping algorithm might say: march thru the
DN from most significant to least significant, gathering DC components as
you go, ignoring non-DC components; when you reach the end if you have a
non-empty DNS name use it as input to the SRV record lookup.  This amounts
to jamming server-location info somewhere in the middle of an existing
naming scheme.  This looser mapping might be attractive to folks who
already have deployed directories with non-DC names, or have applications
that rely on traditional X.521-style civil naming (X.509 PKIs being the
main case, of course), who could add DC components to some lower levels of
their naming hierarchy rather than having to change from the top.

Ultimately this raises the deep issue of what kind of interoperability is
possible and desirable between traditional and DC-style naming.  While
this is interesting and important, I really don't want to wait until it's
resolved in order to progress this document.  Given that the looser
mapping seems trivial for the client to implement, I think the burden of
proof is on those who advocate the current mapping as to why its
restrictiveness is important.  While I personally think DNs with DCs
embedded in them any old place are ugly and I wouldn't design a naming
hierarchy that way, I don't see any fundamental technical problems that
should make them illegal (ie, excluded from the SRV-based location
mechanism).  Maybe others do.

 - RL "Bob"

---

From: David Chadwick <[email-masked]>
Date: Wed, 13 Dec 2000 20:01:29 +0000

Bob

If the question is "given the domain name for an organisation, I need to
find its LDAP server"
then I think the draft as it stands is just fine. An organisation using
X.521 naming e.g. o=university of salford, c=gb, can still use the ID as
it stands by creating a DC based alias entry for its organisation in its
LDAP directory e.g. dc=salford, dc=ac, dc=uk and pointing this to its
X.521 based organisation entry. The client can then use SRV records to
find the TCP/IP address of the LDAP server and send a search request
looking for david chadwick in the dc based organisation. The server will
simply dereference the alias, map the dc organisation alias into the
X.521 organisation and continue the search from there.

Therefore I dont think the ID needs to be altered to accommodate X.521
based LDAP servers. They simply need to add an alias for their domain
name into their LDAP server.

David

(note. if my original question is not the one that the X.521 guys are
wanting to answer, then if they tell me what it is, I will see if that
is answerable with a different solution)

-- 
*****************************************************************

David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
Mobile: +44 790 167 0359
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J

*****************************************************************

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 13 Dec 2000 14:42:22 -0800 (PST)

On Wed, 13 Dec 2000, David Chadwick wrote:

> If the question is "given the domain name for an organisation, I need
> to find its LDAP server"

This is not the problem the ldapext-locate document is trying to solve.
Rather, it is solving the problem:  given a DN, how do I find (via the
DNS) an LDAP server that contains the entry with that DN.  It chooses
to solve that problem only for the class of DNs whose most significant
RDNs are of type DC.

> is answerable with a different solution)

Upon further discussion, the situation is stated like this.  Some
organizations have large deployments using traditional X.500 civil naming
(o=Example Corp, c=nu).  They also have issued X.509 certificates using
those names.  They are as aware as anyone of the absence of a worldwide
X.500 directory, and would like to take advantage of clients that can use
SRV records to locate LDAP servers given a DN (eg, the DN of a cert
issuer).  Adding directory contexts with DCs in them in lower levels of
their existing hierarchy they see as much easier and less disruptive than
establishing an entirely new naming hierarchy (while acknowledging that
DNs have to change in either case).  And based on this they ask what the
technical justification is for using the mapping specified in
ldapext-locate versus a looser mapping that would let them (as they see
it) transition more easily.  If the justification is "purity", or
attitudes of how naming hierarchies should be designed in practice, then
the assertion is that design of naming hierarchies should be left to
deployers.

> X.521 organisation and continue the search from there.

Hmm.  Do existing LDAP servers uniformly support this?  (not that it
answers the question on the table ...)

 - RL "Bob"

---

From: David Chadwick <[email-masked]>
Date: Thu, 14 Dec 2000 16:20:31 +0000

RL 'Bob' Morgan wrote:
> DNs have to change in either case).

Now I dont see how this will work. If the CA already has an X.521 name
form with lots (thousands possibly) of issued certificates, how will it
help those thousands of certificates to create a new name with DCs at
the bottom of it. The certificates have not changed, so wont know about
this new DC extended name. You obviously are not suggesting re-issuing
the certificates, otherwise a simple transition to pure DC based naming
could be done at the same time.

So could you please explain how this DC extended name is going to help?

If I were to solve this problem I would create a CA name based on DC 
naming and put this in all new certificates, still using X521 naming for
everything else. Then the certificate user can look up the LDAP server
of the CA, using the mechanism proposed in the current ID. Eventually
everyone would migrate to this new scheme. But it would not solve the
problem for existing users.

Were you aware that an ID was presented to the PKIX group in Pittsburg
(authors were Sharon Boeyen of Entrust and someone else I believe) who
were also trying to solve this problem. There solution if I remember
correctly (unfortunately I cannot find a copy of their ID) was to use
the email address of the user, which is often stored in the certificate,
to find the LDAP server via SRV records. Since the Email address is
already a DNS name, no DC mapping is needed. The disadvantage comes for
users whose email addresses are not provided by the same organisation as
the CA (e.g. a hotmail address in a certificate issued by Verisign).

David
>  And based on this they ask what the

David Chadwick, BSc PhD

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 14 Dec 2000 09:19:11 -0800 (PST)

On Thu, 14 Dec 2000, David Chadwick wrote:

> form with lots (thousands possibly) of issued certificates, how will
> it help those thousands of certificates to create a new name with DCs
> at the bottom of it. The certificates have not changed, so wont know
> about this new DC extended name. You obviously are not suggesting
> re-issuing the certificates, otherwise a simple transition to pure DC
> based naming could be done at the same time.

No, it's understood by these folks that certs have to be reissued with the
new DC-in-the-middle DNs in order to take advantage of SRV record lookup.
As I wrote in my previous note:

  Adding directory contexts with DCs in them in lower levels of
  their existing hierarchy they see as much easier and less disruptive
  than establishing an entirely new naming hierarchy (while acknowledging
  that DNs have to change in either case).

Arguments about ease-of-deployment are always difficult to assess.  Is it
substantially easier, if one is motivated to take advantage of SRV lookup
for DNs, to modify lower levels of one's non-DC-based hierarchy, or start
afresh with DC at the top?  As an institutional directory deployer I've
done the start-fresh thing twice now (as you suggest you would do) and it
wasn't so bad, but then certs weren't involved in either case; and it got
us to naming hierarchies that make sense, IMHO, for a long time.

But we all know how naming is.  Design choices that mandate particular
naming choices always get resistance, so, all other things being equal,
designs that are naming-independent are better.  The question remains
whether there is any technical reason not to provide the extra flexibility
these folks are asking for.  I haven't heard any yet.  If there is any, it
may have to do with having to scan the whole DN rather than being able to
specify some termination point for the mapping algorithm.

I suppose there is the operational situation that some number of clients
are already deployed that use the strict mapping specified in
ldapext-locate.  So we might ask whether the above deployment concerns
warrant revving these clients.  But in my experience in the IETF, an
installed based of pre-standard software hasn't ever been a good argument
for not doing the right thing.

> were also trying to solve this problem. Their solution if I remember
> the email address of the user, which is often stored in the
> certificate, to find the LDAP server via SRV records. Since the Email
> address is already a DNS name, no DC mapping is needed. The
> disadvantage comes for users whose email addresses are not provided by
> the same organisation as the CA (e.g. a hotmail address in a
> certificate issued by Verisign).

I think you mean draft-ietf-pkix-pkixrep-00.txt.  This is doing a
different task: starting with a DNS name, how do you find a PKIX cert
repository containing certs that somehow relate to that DNS name (among
other problems with this document, exactly what it's solving is poorly
specified; it was suggested at PKIX that it go to Experimental status).

Once you start talking about cert contents, things are infinitely
fungible; look at, eg, the Subject Information Access extension described
in draft-ietf-pkix-new-part1-03.txt section 4.2.2.2, which might be used
to find a directory containing info about a subject.  It can be argued
that findability of directories based on bare DNs doesn't matter, since
there are so many other ways to do it, when you're interpreting a cert.
But the problem draft-ietf-ldapext-locate is trying to solve is finding a
DS based on a DN, which I suspect folks in our community think is a
worthwhile problem to solve.

 - RL "Bob"

---

From: David Chadwick <[email-masked]>
Date: Sun, 17 Dec 2000 22:58:58 -0800

Bob

I question your assertion above on several counts. Firstly locate is not
trying to solve the above for the general case, but only for a very
limited case. Quoting from locate it states

"This method takes advantage of the global
   deployment of the DNS, by allowing LDAP server location information
   for any existing DNS domain to be published by creating the records
   described below. "

Thus locate is only solving the problem once you have a domain name or a
dc based DN to map into a domain name. It does not even pretend to be
solving the general problem you outlined above. This is OK, since domain
names are widely known and used.

Secondly, I think the problem itself is something of an oxymoron. DNs
are not widely known or used. You actually use an LDAP directory to find
a DN if you want one, not the other way around. People usually dont know
DNs, nor do they really care what they are. Therefore if a client has in
its possession a DN it must have come from somewhere. If it came from a
certificate, then as you say there are alternative ways of finding the
LDAP server from the contents of the certificate, rather than doing some
arbitrary DN mapping based on the subject DN. If it did not come from a
certificate, but some other place, then why not get the other place to
pass an LDAP URL containing the DN, rather than just the DN on its own.
This would solve the problem nicely. After all URLs are a much more
common currency than DNs.

Finally we as a group should really be trying harder to help LDAP
servers hold more knowledge information about each other, then the
problem above tends to disappear since a client then only needs to know
about one LDAP server and this will plug it into the rest of the LDAP
world. Imagine how the DNS would operate if every resolver had to find
the location of the DNS server it wanted before it could make domain
look ups.

I therefore seriously question whether the general problem you outline
above is a sensible one that we should even be attempting to solve.

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 17 Dec 2000 17:56:56 -0800

RFC 2247 itself introduces an algorithm for transforming any
domain name to a DN *AND* to convert these DNs back into the
original domain names (last paragraph of section 3).

The purpose of the Locate I-D is to more fully specify the DN
to DNS mapping and to provide DNS SRV capabilities.

Like RFC 2247, the locate I-D should not define (nor preclude)
other DNS/DN equivalences.

If there may be other useful DNS/DN equivalences, they should
be specified separately from RFC2247/locate.

Kurt