Re: Basic Cert-2-Directory mapping question

[Janus Liebregts <Janus.Liebregts@xxxxxxxxxx>]

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.