[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Basic Cert-2-Directory mapping question

Peter,

Stephen Kent <kent@xxxxxxx> writes:
>At 9:08 AM +0100 1/10/01, Michael StrM-vder wrote:
>>=> People are used to flat name spaces. X.500 DNs does not work.
>
>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.

Have you actually seen the problem though? It's automatically assumed that
there's some vast, unassailable problem which hierarchical names will solve,
but I don't think I've ever seen it except as some special-case, often
hypothetical situation which is used to justify the need for DNs (or whatever).

Well, hierarchic names do solve several problems, as I noted in an earlier message today. DNS is a great example. X.500 is not so great an example, for reasons I also allude to. LDAP is not a great example for various reasons, including the fact that in making it "L" folks threw out things they later realized that they needed. This has several analogies to the history of e-mail systems. Internet e-mail was basic but fairly solid and very widely implementable, like DNS. Fancier e-mail system evolved, but were platform specific and often were restricted to the set of users managed from a single server or a small set of servers under single administrative control, and thus didn't scale, like LDAP. Now that we have MIME, we have most of the best of both worlds, i.e., a scalable system with tremendous extent and the ability to handle arbitrary content. But, I digress ...

In the real world people have been using their flat, non-scalable name spaces
for several decades without any sign that civilisation is about to collapse.
Only yesterday I was talking to someone whose company is deploying a nationwide
PKI based on HTTP (you tack the ID of the cert owner onto a URL and grab it
from a server, revocation is handled by removing the cert). Since it's HTTP,
it's guaranteed to work through firewalls, proxies, and other oddities, and is
supported on every platform, I shudder to think what it would take to do the
same thing with CRLs and directories and DNs and whatnot.

Not sure which "flat, non-scalable name spaces" you are alluding to above. As for your example, I don't see how scaling works in your HTTP PKI example. If the cert ID isn't structured, then does one server (or server family) hold all the certs? That's not scaleable. Also, revocation via removal from a directory is a questionable notion, as it implies a need to always access the directory (not supportive of many scenarios) and to place a lot of trust in the directory (not a great security concept).

In the real world we use flat IDs for practically everything where certs might
at some stage be employed without any problems, for example:

- Access to University account information (Uni. ID number)

That's not a flat ID if you have to specify the university ID; it's a 2 level hierarchy.

- Access to/submission of tax info (taxpayer ID, SSN in the US I guess)

Not quite. Since SSNs are not unique, its the name and SSN that is used, and the system. Still, for global applicability one would prefix the ID with a country code, again making it a two tier scheme.

- Email encryption (email address)

definitely NOT a flat space, because it is build on top of DNS, which is already hierarchic.

- Access to/update of frequent flyer info (frequent flyer number, living
where I do you get handed one of these the first time you buy a ticket :-).

Airline specific, so a global system uses an implied airline ID.

- Bank account access (account number)

Again, requires bank ID first to qualify the account number.

- Access to patient medical records (from the discussion yesterday, this uses
some doctor registration number which is centrally managed)

Can't comment here since the U.S. does not have a national, medical care system, but I assume that here too we would need to qualify the ID by country first.


There isn't actually anything I do which needs a hierarchical DN or any of the
accompanying paraphernalia and complexity (X.500/LDAP/whatever), in every case
a simple "Get me the cert for <flat, non-hierarchical, just plain works ID>"
will do the job.  What major, urgent real-world problem (apart from "Lack of
revenue from selling X.500 services"), which couldn't be addressed much more
simply with existing mechanisms, are DNs et al actually solving?

We have a very bad disconnect here, Peter. What I see above are example of name spaces that are very much hierarchic, but usually shallow hierarchies. What I think you have intended to say, but did not until this paragraph, is that the DN structure based on countries, and organizations or geographic locales seems richer than one needs for most naming scenarios where we might want to issue certs. I think that's true only if one assumes additional context, as shown in each example above, and that context might be external to the name, or it might be part of the name to make the name globally unique.

<snip>


Steve