Re: Basic Cert-2-Directory mapping question

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

"Anders Rundgren" <anders.rundgren@xxxxxxxxx> writes:
 
>The question rephrased: How could an RFC2459-compliant cert using an 
>arbitrary DN map in an equally arbitrary X.500-compliant directory?  
>Arbitrary could also be expressed in this context as: The certs are not 
>tailor-made for this particular directory.  This is what you get if you for 
>example buy a Swedish Electronic ID-card based on a citizen registration 
>system that usually have no relevance in a private company.  Still you would 
>like to use it in that context and the question is how?  The answer is 
>mapping and my question was how you do that using *directory technology* 
>using an (hopefully) standardized method. 
 
You can't do it.  Actually the answer is a lot more complex than that, I 
looked at it in my ACASC'00 paper on certificate stores which should be 
available from http://www.acsac.org, this is a shorter version due to size 
constraints of a somewhat longer work which I'll put on my home page within 
the next week or two (it's the middle of the summer break over here, so some 
things are running at a low priority).
 
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.
 
That's the short version, the longer one, with a fairly detailed analysis of 
requirements and performance issues, will be on the paper I'll have on my home 
page and in the ACSAC version.
 
Peter.
 
[0] Strictly speaking this should say "After ~15 years of trying to make them 
    work noone's really managed it", but I usually generalise it to "DN's 
    don't work" to save having to update the year count every year or so.
 
[1] One somewhat surprising thing I found out during and after publishing the 
    paper is how many vendors are actually using RDBMS' as cert stores, even 
    if they have to bolt an X.500/LDAP interface on top of them.  I only know 
    of one vendor which isn't using either an RDBMS or dbm with an X.500 glue 
    layer on top for their cert store (not counting toy stuff like MS using 
    the registry to store certs).