RE: LDAP server location and DN->DNS mapping

["Slone, Skip" <skip.slone@lmco.com>]

I agree with David in that I don't believe the approach of extracting any
embedded dc elements solves the problem.  In addition, the appending of dc
elements to the least-significant end of a DN appears to introduce some
potentially disruptive semantic changes into the nature of a DN itself, but
I'll save that for another discussion.

To address the issue at hand (LDAP server location), my company is making
definite moves in the direction of dc-based DNs. However, the same cannot
necessarily be said for our 65,000 or so trading partners.  Many of those
are likely to continue using the civil naming approach indefinitely.
Regardless what approach they take, we will need to be able to resolve their
names and find their associated directory entries.  What we need, therefore,
is a deterministic algorithm that gets us from any arbitrary DN to a
cognizant LDAP server (or to a definitive determination of the non-existence
of such a server).

I've been giving this matter considerable thought lately, and have a
somewhat embryonic idea to propose for discussion. Unfortunately, I don't
have it fully articulated just yet, and am getting ready to disappear from
the scene until January 2.  Nonetheless, at the risk of generating a
firestorm just as I leave for for vacation :-), I'll share my thinking:

1) continue to use dc/SRV mapping as presently defined.
2) define a mapping between c=XX and dc=<ccTLD> (with special mappings as
needed to handle cases like c=GB --> dc=uk)
3) define a new RR type (for sake of discussion, let's call it an O-record)
that resolves o=<orgName> to a fully qualified domain name (much like a
CNAME RR, but with a different label field).

Items 2 and 3 would give us the ability to deterministically map DNs of the
form "o=Something, c=ZZ" to an arbitrary domain name, which could then be
queried for LDAP services as if the DN ended in the dc equivalent of that
domain name.

As an example, my company could (hypothetically, of course) register with
the owner of the .us domain, who would create an O-record with the label
field equal to "Lockheed Martin" and a data field of, say "lmco.com".  Thus,
a DN ending in "o=Lockheed Martin, c=US" would query .us, receiving
"lmco.com" in response.  (Note that this maps across TLDs without
difficulty.)

4) building on this concept, define another new RR type (for sake of
discussion, let's call it an OU-record) that queries the domain returned by
step 3 and resolves ou=<orgUnitName> to a fully qualified domain name.

Items 2 through 4 now give us the ability to deterministically map DNs of
the form "ou=Some org unit, o=Some Company, c=ZZ" to an arbitrary domain
name.

5) apply 4 recursively, querying the domain previously returned and we can
have an arbitrarily deep mapping.

Noting the similarities between the O-record and OU-record above, it might
be meaningful to consider a more general-purpose RR type instead (let's call
it an AVA-record, replacing both the O-record and OU-record), for which the
label field is defined as an arbitrary attribute value assertion such as
"o=Company Name". This AVA record could then collapse steps 3 through 5 into
a single step, applied recursively, giving us the ability to resolve any
country-rooted DN to a domain name.  That domain name could then be used in
the same manner as if the DN itself were a dc-style DN as known today.

This also opens the possibility of adding to the current dc algorithm to
intersperse dc and civil attribute types in the DN. Much more thought needs
to be applied to this, but it looks like a deterministic algorithm is within
reach. 

Obviously, there are many, many issues to be worked through, not the least
of which are the registration issues at the ccTLD level and issues of what
to do with non-country/non-dc rooted DNs. However, it seems to me that there
might be something here worth pursuing.

Any thoughts?

 -- Skip Slone
    Lockheed Martin

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
Sent: Thursday, December 14, 2000 11:21 AM
To: RL 'Bob' Morgan
Cc: IETF ldapext WG
Subject: Re: LDAP server location and DN->DNS mapping




RL 'Bob' Morgan wrote:
> 
> 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).

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
> 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.
> 
> > 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.
> 
> Hmm.  Do existing LDAP servers uniformly support this?  (not that it
> answers the question on the table ...)
> 
>  - RL "Bob"

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

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: D.W.Chadwick@salford.ac.uk
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

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