Re: LDAP server location and DN->DNS mapping

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

On Thu, 14 Dec 2000, David Chadwick wrote:

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

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 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. Their 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).

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"