Re: [tf-lsd] Re: Basic Cert-2-Directory mapping question

["John McGarvey" <mcgarvey@xxxxxxxxxx>]

Janus,
In describing the Microsoft case, you put your finger right on the problem.
There is no guarantee that the LDAP directory to be used by a given
application, and the CA that issues a certificate, adhere to the same
namespace rules or are administered by the same processes or people.  So
the certificate DN may not correspond to any DN in the directory.  This
problem will often occur in eBusiness or B2B applications, when the
certificates may be issued by well known public CAs, but the directory in
which policies, preferences, and whitepages information is stored is
maintained by a given enterprise or web hosting service.  Also, there is no
guarantee that the DNs in the certificates uniquely identify the same
principal.  Different well known CAs might use the same DN to describe
different principals.

If one is building a CA infrastructure and a directory infrastructure
together, of course one can make the certificate DNs match the LDAP DNs.
But, as it is often the case that the two are constructed separately, there
needs to be a means of mapping from one to the other.

Regards,
John McGarvey


Janus Liebregts <Janus.Liebregts@xxxxxxxxxx>@terena.nl on 2001/01/09
08:56:44 AM

Please respond to tf-lsd@xxxxxxxxx

Sent by:  owner-tf-lsd@xxxxxxxxx


To:   Anders Rundgren <anders.rundgren@xxxxxxxxx>
cc:   ietf-pkix@xxxxxxx, tf-lsd@xxxxxxxxx, pki-coord@xxxxxxxxx, "Bosch,
      J.C.F.v.d." <J.C.F.v.d.Bosch@xxxxxx>
Subject:  [tf-lsd] Re: Basic Cert-2-Directory mapping question



Anders,

as far as we have tested: you can use certs using X.521 naming in a
win2k local authentication environment, the only restriction is that the
issuing-CA HAS to be a MS enterprise CA and thus has to use dc-naming
(in the current win2000-version).

janus

Anders Rundgren wrote:
>
> Janus,
> Unforntunately your certificates will not be useful for Win2K local
authentication
> due to this mapping problem.  Does Novell offer a more flexible use of
> TTP-issued certificates without requiring the RP to use a 1-2-1 DN
> versus directory mapping?
>
> /anders
>
> > I fully agree with David.
> >
> > I don't agree that using a standard DN registration scheme, is
> > extraordinarily painful. Currently we, SURFnet (as the dutch National
> > Research Network) use two simple rules for our pki-domain (Higher
> > Education & Research):
> >
> > 1. only certify CA's using DN's as registered within our (LDAP)domain
> > using the rules of our Naming Authority.
> > 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.
> >
> > with this we build our pki according to the ldap-namespace ACCORDING to
> > SURFnet. We claim to be the Naming Authority for the C=NL namespace...
> >
> > Probably every country & state have their own laws about naming
> > organisations, in Holland the Chambres of Commerce have such a
> > (delegated) task. Every country (C= or state c=US, ST=) should have
some
> > sort of naming authority and name-registration is already taken place.
> > But how to make available these authorative Naming databases in a
(LDAP)
> > way, to be the authorative name for certification....
> >
> > For our community we have made available a pki-ldap cookbook which
> > describes a method how to organise your DIT and how to store
pki-related
> > material http://ldap.gigacorp.nl/pkildap.html
> >
> > Janus Liebregts
> > SURFnet
> >
> >
> >
> >
> > "David P. Kemp" wrote:
> > >
> > > Peter,
> > >
> > > I thought what Anders asked was:
> > >   "given an arbitrary DN, how do I find a cert stored somewhere in an
> > >   arbitrary collection of independently-managed X.500 or LDAP
directory
> > >   servers",
> > >
> > > not:
> > >   "given an arbitrary DN, how do I fetch a cert which I already have
a
> > >   copy of, stored on my own server."
> > >
> > > It shouldn't be at all surprising that a db or ISAM store, with or
> > > without an RDBMS layer above, and with or without a DAP or LDAP
access
> > > layer, is a reasonable way to store certs on your own machine. [1]
> > > Developing a DN-schema-independent local retrieval mechanism is all
> > > well and good, but it doesn't solve the registration problem, and as
a
> > > result, it doesn't help you to find a cert which you don't already
> > > have.
> > >
> > > The real problem with finding and using certs which are stored
> > > elsewhere is the reverse of what you stated, namely:
> > >
> > > cause:  people fill DNs with whatever they like, and therefore
> > > effect: those particular DN's don't work (i.e. they don't solve
> > >         Anders' question because they aren't valid addresses in
> > >         a global address space.)
> > >
> > > Instead of saying "DN's don't work", with a footnote, it would
> > > be more accurate to say "people choose not to use working DNs".
> > >
> > > The Web works only because every Internet URL begins with
> > > DNS-registered name. Something related to your third approach below,
> > > requiring all certs and directories to use a standard DN registration
> > > scheme, may be extraordinarily painful, but it's better than ad-hoc
> > > workarounds using other certificate fields.  If PKI consumers and
> > > providers aren't willing to standardise within a global DN space, we
> > > will have only islands of interoperability. [2]
> > >
> > > Dave
> > >
> > > [1] You could also just use the native filesystem, storing each cert
> > > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)
-based
> > > flat folder.  This works as long as you keep secondary indices
> > > synchronised with the folder contents, or if you don't need secondary
> > > indices at all.
> > >
> > > [2] Blue sky thought:  it might be nice if there were a "Registration
> > > Point (RP)" DN attribute which would be analogous to the hostname
> > > portion of a URL.  The RP attribute would be the first RDN of a
> > > DN, and the RP value would be an OID identifying the registration
> > > authority and the schema for the remainder of the DN.  In principle,
> > > this is no better (except for being less verbose) than current DNs,
but
> > > in practice OIDs are better managed - people actually choose to
follow
> > > OID registration procedures instead of just poaching in somebody
else's
> > > space.
> > >
> > > > From: pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)
> > > >
> > > > The main problem is that DN's don't work [0], so you end up with
ones which
> > > > people have filled with whatever they feel like, odd things
required by cert
> > > > profiles or signature laws or organisational constraints or
whatever which
> > > > generally don't fit any known directory schema.  The current
approaches to
> > > > this problem if you're using a directory as a cert store are:
> > > >
> > > >   - Continually update the directory schema to match any new DNs
which appear
> > > >     until the directory admin(s) go insane (hi Paul :-).
> > > >   - Create aliases in the directory mapping DNs in certs to the
(fixed)
> > > >     directory schema.
> > > >   - Force all certs to use the schema used in the directory
(someone who's
> > > >     been through this one once described it to me as
"extraordinarily
> > > painful").
> > > >   - Use the directory DN to identify the cert owner and store the
cert as just
> > > >     another attribute, with the actual cert DN ignored.
> > > >   - (There may be more, since the whole thing is badly broken there
are
> > > >      probably lots of workarounds being used.  If anyone knows of
others
> > > >      please let me know)
> > > >
> > > > A much better approach IMNSHO, and the one I look at in my paper,
is to treat
> > > > the DN as a blob and hash it down to a fixed-length value which you
use as a
> > > > key to look up the cert in an RDBMS or something like dbm if you
don't need
> > > > the full RDBMS functionality [1].  This approach just plain works
no matter
> > > > how garbled and broken the DN is.