Re: Basic Cert-2-Directory mapping question

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxxxxxxxxxxx>]

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.