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

From: [email-masked] (Peter Gutmann)
Date: Thu, 11 Jan 2001 17:11:21 (NZDT)

Stephen Kent <[email-masked]> 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).
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.
 
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)
  - Access to/submission of tax info (taxpayer ID, SSN in the US I guess)
  - Email encryption (email address)
  - 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 :-).
  - Bank account access (account number)
  - Access to patient medical records (from the discussion yesterday, this uses
    some doctor registration number which is centrally managed)
 
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?
 
[I should add an addendum here that the person I was talking to asked me about
 switching to LDAP, since he'd read about it a bit in the trade press and
 wanted to know what was involved.  I started to run through the standard
 5-minute intro to X.500 and LDAP and he looked at me as if he expected a
 cuckoo to pop out of my forehead on a small spring... I doubt they'll be
 switching over any time soon]
 
Peter.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 11 Jan 2001 07:10:44 +0100

Peter,

> for several decades without any sign that civilisation is about to collapse.

I second that 100%.  The only thing you gain by hierarchical cert names is rigidness
(i.e. can only be used in a certain regime) and low trace ability (change position
and then you become another identity).  So even for closed PKI's we do have
a serious mapping issue IMNSHO.

Anders

---

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

Peter Gutmann wrote:
> 
> Only yesterday I was talking to someone whose company is
> deploying a nationwide PKI based on HTTP
> [..]
> [I should add an addendum here that the person I was talking
> to asked me about switching to LDAP, since he'd read about it
> a bit in the trade press and wanted to know what was involved.
> I started to run through the standard 5-minute intro to X.500
> and LDAP and he looked at me as if he expected a cuckoo to pop
> out of my forehead on a small spring... I doubt they'll be

Maybe you should have showed him how easy it is to retrieve an
e-mail certificate when writing e-mail which is stored in a
directory. I really like LDAP for being a standard access protocol
which I can use in mainstream e-mail apps (get a certificate within
an organization with just two more clicks) and in a few lines of
Python/Perl/TCL/PHP code. I don't care that much about the
hierarchical DNs though.

Ciao, Michael.

---

From: Polar Humenn <[email-masked]>
Date: Thu, 11 Jan 2001 09:00:14 -0500 (EST)

> a serious mapping issue IMNSHO.

I'll jump on the band wagon as Peter, Anders, and a few others. DN's to
me, have never been hierarchical. They are basically converted to strings,
or hashed, and used, searched for, and compared, that way. I really enjoy
the "flat" name space, Simple, and normal people, as well as "simple"
programmers know how to deal with it. It's not really flat, but comes in
two parts. 1. tell me where to find it, 2 and tell me how to find it from
there. HTTP is just one good example illustrated by Peter, SDSI (SPKI?) is
another. (And I for one, like that revocation scheme, much better then
trying to find CRLs and calculate delta CRLs, what a waste of precious
processing time!). The whole X.500 thing, in my mind is so bizzare. It's
so complex, and with OSCP servers, and DPV and such, the whole thing is
going to start looking like Kerberos pretty soon, which has one of these
so called flat namespaces.

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 11:51:03 -0500

Anders,

>a serious mapping issue IMNSHO.

Hierarchic name spaces are desirable for many reasons irrespective of 
the narrow focus of this discussion. (Note that DNS is an example of 
such a name space.)  They are attractive because they allow easy 
distribution of name creation without fear of collision, and if one 
aligns repositories with the name space, distribution of the database 
is also facilitated. X.500 has not been widely successful, in part 
because there is no authority to impose name space constraints, 
mediate disputes, etc. DNS is successful because we have such 
authorities and because folks are motivated to operate their parts of 
the tree reliably, else Internet access is dramatically affected. So, 
don't confuse X.500 problems with hierarchic name space problems.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 12:01:48 -0500

Polar,

>so called flat namespaces.

You're confused. DNs are hierarchical, by definition. That's not open 
to debate; it is a function of the fact that they are directory 
distinguished names, inherited from X.500, as Sharon has pointed out. 
The fact that some people may have chosen to treat them in other ways 
does not change the semantics of the name form, as specified by many 
standards.

Kerberos may be good example of a flat name space, but only within a 
single realm, i.e., to scale beyond one realm one must use a name 
with a realm ID. That already makes it a two level, not flat, name 
space. Only by imposing conventions on Kerberos names, tied to the 
DNS (which, last time I looked, was hierarchical) does one manage to 
ensure uniqueness, scaleability, and locatability for KDCs 
(piggybacking on DNS).

All the criticisms re hierarchic name spaces apply not only to DNs 
but to DNS names as well, a system that enables us to engage in this 
debate via e-mail. The limitations of poor use of hierarchic names 
spaces is also evident in the DNS, mostly in the form of the legacy 
TLDs: .com, .net, .org, .mil, .gov, .edu.  These flatten the space 
considerably and overload the system, except where we have become 
xenocentric and restricted use of U.S. entities (e.g., for gov and 
mil). Whne Jon Postel managed name assignment, people could rely on 
.org and .net being appropriately assigned, something that is no 
longer true. The rush for every company and many individuals to be 
listed under .com. vs. under country codes that then can have a .com 
subdomain, has diminished the benefits that should result from this 
structure, and places greater and greater demands on the server 
infrastructure.

I already explained why hierarchic name spaces are desirable, so I 
won't repeat the arguments. Despite all the fun that results from 
this discussion, PKIX is not the right forum in which to have the 
debate.  We're not a directory WG.  We support various options for 
names, thanks to the generalname construct of v3 certs. It's useful 
to discuss how to solve problems related to cert repository 
discovery, but since we are not a directory WG, keep in mind the 
limitations on our ability to influence the results of such 
discussions.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 16:20:50 -0500

Peter,

>hypothetical situation which is used to justify the need for DNs (or 

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 ...

>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).

>   - 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.

>     where I do you get handed one of these the first time you buy a 

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.

>     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.

>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