Re: Basic Cert-2-Directory mapping question

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

John, as I said, I don't care much what the syntax is.  I don't mean 
to suggest that such details aren't important, but they wouldn't 
make or break the Internet. There is a community of applications 
(like browsers, etc.) that are used to dealing with URLs, but your 
suggestion of a "super-top" class could also be made to work.

Your suggestion would also have the implicit implication (I guess that's
redundant) that the lower levels of the RDN tree are subordinate to, 
and defined within, the top level directory., and that might be desirable.

What we need, and have needed for ten years, is a STANDARD!

Bob

Aside to David Kemp -- mail sent to your return address of 
dpkemp@xxxxxxxxxxxxxxxxxxxxxxx bounces with "User unknown".


>>> <John_Wray@xxxxxxxx> 01/09/01 07:32AM >>>

Bob,

Accepting the fact that the X.500 dream of a single global directory is not
going to happen any time soon, DNs can still be turned into globally
significant pointers into a federation of directories in the way you
suggest, but it doesn't require altering the DN syntax (and therefore
doesn't have to break existing implementations).  All that's needed is a DN
attribute that names the particular directory within which the name
resides.  e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
directory access point.

John





"Bob Jueneman" <bjueneman@xxxxxxxxxx> on 01/08/2001 04:56:58 PM

To:   <ietf-pkix@xxxxxxx>, <dpkemp@xxxxxxxxxxxxxxxxxxxxxxx>
cc:
Subject:  Re: Basic Cert-2-Directory mapping question


This has been a train wreck about the happen for nearly ten years.
It's like watching "The Fugitive" one still frame at a time.  The NADF
tried to address this problem and gave up, and PKIX hasn't even tried.

To quote Pogo, "We have met the enemy, and they is us."

The first problem is not the DN -- that's secondary.  As you correctly
state, the first problem is knowing the location of a directory service
provider that is supposed to contain the DN, so we can at least get
to the right point and start browsing around for a certificate.

I don't know that we need to name a Registration Point for a DN -- that
might get all tangled up in naming issues, who has the right to name
someone, etc.

What I proposed more than a year ago, and what I think you are in
essence saying, was that DNs in certificate should really be URLs,
in essentially the same fashion as CRLDistributionPoints are.

I don't particularly care what the exact syntax is -- something like

    ldap://ldap.mycompany.com/c=us, ....cn="My Name"

would do just fine, I think, but I'll let other people debate that.

Once we finally locate the directory, then we can have all of the religious
arguments about my RDN schema vs. yours, and why yours is wrong and mine
is the only one that any right-thinking system administer could possibly
support, yada, yada, yada.

Unfortunately, since the contents of PKI certificates are generally viewed
as supposedly providing some degree of specificity with regard to a
geopolitical
identification and location of an end-entity, those schemas sometimes
conflict with
directory structures which are often organized around completely different
principles, such as more or less reflecting the network structure or
topology
or span of control issues.

But those issues, although certainly important, could reasonably be
resolved by
aliases, etc., no matter how painful  But if a consumer of certificates
doesn't even
know where the directory can be found to start looking, then schema
problems
won't matter.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> "David P. Kemp" <dpkemp@xxxxxxxxxxxxxxxxxxxxxxx> 01/08/01 11:29AM >>>
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.