Re: Basic Cert-2-Directory mapping question

[Janus Liebregts <Janus.Liebregts@xxxxxxxxxx>]

Bob,

every country has its own monopoly on local law, every country has a tax
department which have to distinguish which company and which citizen has
to pay tax.

There should be some sort of distinguishing between companies and
citizens done by authorities. Mapping of names, which can be used under
this law, has to be done in every country.

I think the problem is really simple, you can use a name not recognized
by your law, but one of the CA's in your pki-hierarchy has to give some
guarantee of this CA is operating under a CPS AND a certain law to be
trustworthy. Some kind of company or citizen has to provide this
guarantee. How do you sue a CSP if you don't know under which identity
(recognized by some law) he operates?

This is a main issue when doing business using pki-technology in between
2 or more legal systems.

janus

Bob Jueneman wrote:
> 
> Unfortunately, the model you cite, with naming authorities that
> are truly authoritative, and in addition a monopoly, is in fact NOT the
> case the United States, and in a number of other countries in the
> world as well.
> 
> If the government decrees what DNs are allowable, and perhaps where
> they have to be stored, then the problem is certainly simplified.
> Unfortunately, usually isn't the case.
> 
> Bob
> 
> >>> Janus Liebregts <Janus.Liebregts@xxxxxxxxxx> 01/08/01 01:36PM >>>
> 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.