Subject: Re: Basic Cert-2-Directory mapping question

From: [email-masked] (Peter Gutmann)
Date: Mon, 8 Jan 2001 05:07:53 (NZDT)

"Anders Rundgren" <[email-masked]> 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).

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 7 Jan 2001 18:45:25 +0100

Peter,
Thanx for the very elaborate answer that matched my worst fears about TTP-issued
certificates!  I could not find your paper though - please send me it directly and I will respond
with a paper that I am currently working on, on how to solve this problem.  Would you
BTW be interested in participating in a BOF-like feasibility study to see if DNs must continue
to be broken until the end of time?  Or maybe you have already given IYNSHO the likely outcome of
such a study :-):-)

/Anders

> Anders Rundgren writes:

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Jan 2001 10:40:10 -0500

Peter,

I have not read your paper, but the assertion that DNs don't work, 
without substantiation, seems a bit strong.  Certainly when people 
create arbitrary DNs, without regard to the semantics of directory 
structure, bad things happen. Also, it is fair to say that the grand, 
nations as top level directory operators model that X.500 envisioned 
has not happened, and it unlikely to ever happen in some places, 
e.g., the U.S. However, the suggestion of hashing a DN and using it 
as a search key always seems to have the problem of breaking the 
knowledge reference part of X.500 (and of all, analogous, tree 
structure, distributed directories), which rely on looking at name 
structure to figure out where to look for an entry that is not local.

finally, the IETF has had a standard means of encoding a DNS name as 
a DN for several years, which suggests that there is at least one 
scheme that would work.

Steve

---

From: Michael Ströder <[email-masked]>
Date: Wed, 10 Jan 2001 09:08:49 +0100

Stephen Kent wrote:
> structure, bad things happen.

Please review some discussion threads on LDAP-related lists about
directory tree design........................never-ending story.

Suggestions are ranging from traditional X.521 naming to flat-tree
name space under a dc=domain,dc=domain root.

> Also, it is fair to say that the grand,
> has not happened,

Even if it would have happened X.521 tree naming would simply suck.
Think of multi-national companies which are not eager revealing
their directory structure to the public. Not to speak of the
different country-dependent rules for the registration process...

> a DN for several years, which suggests that there is at least one

I agree that DNS-based naming (often called dc naming in the LDAP
world) is a way of at least find a division for global and
organizational name space. System admins are used to it and they
have to sub-divide their organizations into DNS sub domains anyway
(which is a pretty hard job though).

But who of you on the list has a mail address [email-masked] or
even [email-masked]? Will you agree with your admin if
you're assigned such an e-mail address? No, you will ask him for a
shorter one. Or you will go to a cheap free mail service to get a
shorter one. Or register your name as domain (me too ;-).

=> People are used to flat name spaces. X.500 DNs does not work.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 10 Jan 2001 09:08:57 +0100

Anders Rundgren wrote:
> 
> BOF-like feasibility study to see if DNs must continue
> to be broken until the end of time?

The main problem is that the world is not hierarchical or more
precise: There are so many possibilities even within small
organizations to divide them into a hierarchy. Not to speak of
connecting the names spaces of different organizations...

Most X.500 directory books suffer from not accepting this.

Ciao, Michael.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Jan 2001 16:55:38 -0500

At 9:08 AM +0100 1/10/01, Michael Ströder wrote:
><snip>

Flat name spaces scale poorly, lead to confusion, and are thus not 
attractive in various ways.  People do like flat name spaces, until 
they trip over the limitations they embody, then they complain and 
look for magic solutions. I've seen no appropriate magic for this 
problem.

Steve

---

From: Michael Ströder <[email-masked]>
Date: Thu, 11 Jan 2001 11:33:22 +0100

Stephen Kent wrote:
> look for magic solutions.

Now for the X.500/LDAP variant of a "magic solution":

1. An organization tries to find a solution for the flat name space
problem but the managment is clueless.

2. They hire an IT consultant.

3. X.500 is chosen as THE solution (mainly because the X.500 books
the IT consultant read sounded so promising).

4. After discussing weeks or months which DIT rules to use a
hierarchy is defined and written down in a concept paper.

5. The DIT rules are presented but the company's CEO makes some
"strategic" decisions about naming. Mainly he does not like the DN
for his entry because it's too long. He chooses
cn=ceo,dc=famousecommerce,dc=com for his entry and
cn=secretary,dc=famousecommerce,dc=com for his secretary's entry.

6. Again discussing DIT rules according to the new "requirements"
and working out a migration plan. The IT consultant has done his
job...

7. Finally the new X.500 or LDAP server is up and running.
Testing...

8. The directory admin switches off global searches and browsing
mainly for avoiding performance problems.

9. None of the Joe Average user is able to use the new service and
people are still happy with their local address book in their
favourite e-mail app.

10. After a couple of months somebody starts his own flat-named
service and opens it to other users. People are amazed by this "new"
centralized data repository which is easy-to-use...

11. The new service grows to the same scalability problem again.

12. Goto 1.

Don't get me wrong. I am using LDAP servers and I think a directory
service can be very convenient within an organization especially for
retrieving e-mail certificates!

But some of the promises made by directory people were not fulfilled
during the last 10+ years. Still these promises are repeated over
and over again.

> I've seen no appropriate magic for this problem.

Neither have I.

Ciao, Michael.

---

From: "Stefan Kelm" <[email-masked]>
Date: Thu, 11 Jan 2001 13:31:28 +0100

Michael,

> the IT consultant read sounded so promising).

No, in many organisations X.500 is chosen because a directory
is already up and running. You are, however, quite right wrt
the huge problems you mention.

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B