RE: Finding PKIX Servers!

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

On the heat vs. light scale, a lot of the commentary on this thread 
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

In my view, it is pointless to argue for the establishment of some global,
overarching directory structure as a _prerequisite_ for something else we
are trying to do.  As a former member of the North American Directories
Forum that tried to do that, I know that we finally gave up and threw in the
towel -- the problem was just too hard. Was then, and arguably is now. 
That doesn't it will stay that way forever, of course.  We used to talk about 
islands of directories beginning to emerge, and then later forming 
archipelagoes, and later yet merging to form continents. Hopefully this won't
take geological time frames, but it hasn't happened yet.

By the way, the primary problem was NOT technical, but rather intellectual
property issues.  The major value-added network providers at the time were
selling various proprietary directory services to their customers, and they didn't 
want to lose market share by integrating their valuable data into a directory 
that just anyone could access. So they didn't, and now most of them have
disappeared, along with the opportunity to put together a workable 
global system along the lines of what X.500 was ordinally envisioned to be.
Too bad -- a wasted opportunity.

Now, whether we like it of not, we have lots and lots of little islands of X.500 
and X.500-like directories all over the place, especially in the corporate world.

At present, virtually none of these directories are interconnected, except that
clients, including LDAP, can access multiple such directories if they just know 
how to do so.

(Brief digression re LDAP.  When Tim Howes was at U-Mich and wanted to 
deploy directory technology to the 100,000 students there, those students
were equipped with 8088s and 286-based machines that were slow and 
had very limited memory by today's standards.  He looked at DAP and decided,
perhaps rightly, that that protocol (a) provided more functionality than was needed
for his application, (b) was going to take too long to program given the very
limited technical staff that was available, and (c) wouldn't leave enough memory 
in the student's computers to do anything useful.  So he "simplified" the protocol
by throwing out everything he didn't need for his particular application, notably
including support for character sets other than English, strong authentication,
chaining and referral, etc., etc.  And so LDAP was born, and voila! it satisfied 
his needs, and some other early adopter's needs as well.  Now the market has 
spoken, and the answer is LDAP regardless of what the original question was, and 
so we are up to LDAP v3 and are still trying to restore the needed functionality 
and generality that DAP provided, and we are having to do it with lots of string 
parsing instead of more efficient structures, and it sure as heck isn't light weight
any more, and now we are further away then ever from having a global directory. 
Sigh.)

But back to the real world.  Regardless of how it "shoulda" been done, the fact is 
tens of thousands of directory administrators have independently decided how to 
optimize their directory information trees, and guess what -- very, very few of them
took into account issues of globally unambiguous names, common schema, etc..
Most directories that are deployed today do NOT have country=XX at their root, 
most don't use the legal name of the corporation at the organization level,
and most don't follow anything even approximating a common schema, much 
less one that would be very useful for providing the kind of quasi-legal relying 
party information that people tend to expect that a certificate would contain.  

(In fact, once when I was giving a talk on this subject I used to example of my own 
DN (or "context," in NDS-terms), i.e., bjueneman.nsrd.prv.novell, and one person 
nodded approvingly saying that yes, all of their directory names ended in novell as 
well, since they were using NDS and NetWare!!

So this is the current reality, whether we like it or not. By FAR the most widely deployed
directory is NDS, with something on the order of 80 million users.  That's not to say 
that there aren't other directories out there, either as vaporware or for real, but they
don't have anywhere near the deployed base.  And NDS users in general have not
interconnected their directories with other users -- at least not yet.

What they are beginning to do, however, is to try to figure out how they can use their
already deployed directory structure (deployed to provide access control to print and
file servers, originally) to make use of these new-fangled certificate thingumabobs
we call a PKI.  First they are going to make use of their directory structure to support
internal applications, such as to authenticate a user's access to the PeopleSoft 
database so people can look at their 401K status and their other benefits.  

(And BTW, that is going to give rise to the first REAL use of nonrepudiation, one 
that will have nothing whatsoever to do with the commonly discussed model of retail 
commerce or banking, and will in fact be an open PKI where we have to deal 
with the so-called widows and orphans model of relying parties, because people 
will begin to do things that have real legal consequences, such as changing 
their life insurance beneficiaries, and their very real widows and dependents will 
want to rely on the digitally signed copy of the policy changes Dad left them.)

But back to the original point of this thread.  Sooner or later, those companies 
are going to start using S/MIME for their e-mail, including e-mail that goes outside the
company. Likewise, they may open up their firewall a crack to allow external users, e.g.,
customers, to access their networks to place just-in-time manufacturing orders, etc.

In the process, they are going to need to have a way of finding and validating
the certificates that are used to back up a digitally signed transaction, and sooner
or later they are going to get tired of sending the same set of certificates down the 
line over and over again.  Assuming that S/MIME provides a way of knowing the
originator's name, either in the form of a RFC822 e-mail name or some kind of a more
"normal" DN, then LDAP (or DAP) could be used to retrieve that certificate as 
necessary, and could also continue on to retrieve the rest of the certificates in the
chain.

But...

How does the relying party's software know in which directory that user's certificate is 
to be found, much less the issuer's certificate, absent the global PKI/directory in the sky?

In the e-mail name case, the RP is nearly clueless, because the e-mail name doesn't 
necessarily have anything at all to do with the originator's organization.  I routinely 
send to and receive mail from people who are using what appears to be a 
personal e-mail account for business purposes -- for one thing, they might like to 
have a certain consistency in their e-mail address even if they change 
companies.  And some small companies might have started out small and didn't 
have their own e-mail server originally, and continue to contract out that function, 
even if they now issue their own certificates.  So the user's organization DNS name,
the e-mail provider's DNS name, and the CA's DNS name may all be different. And
if one organization includes their DNS name as a DN, and another uses their
geopolitical name as a DN, the problem is close to hopeless.

But even if the user's organization does have a directory, that organization may or may
not be the organization that issued the certificate, and may or may not store that 
certificate in a directory.  If I get a certificate from VeriSign, I am not compelled to store
that certificate in my own organization's directory.  And even if I do, there is no absolute
guarantee that I also store my issuer's certificate in that directory, especially if my issuer's 
name doesn't fit within my own organization's directory schema.  But someone
probably could find my certificate in VeriSign's directory, listed under my name, 
if they only knew to look there (and if VeriSign could figure out how to cope with my
particular schema).

So what I was proposing was a relatively simple, pragmatic solution to this problem.

Some of the previous commentary on this thread took one of two diametrically 
opposed positions -- either that the "only" way to solve this problem was to 
posit a single globally interconnected PKI cum directory; or that such a directory, 
and perhaps even a global PKI was not only unnecessary but undesirable, and 
maybe even unthinkable, even between consenting adults.

I would reject both of those positions.  I just want something that will work in today's
environment, that doesn't require me to take my little immersion heater down to the 
ocean shore and plug it in and wait until the water comes to a boil.

So I'll say again, wouldn't it be a Good Thing if we could have an optional attribute
in a certificate that is associated with the Issuer's name somehow, one that would 
provide the DNS name of an LDAP server that contains the Issuer's certificate?

At this point in time, I don't care particularly what form the attribute takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or it 
could be some other alternateSubjectName attribute, or some other attribute entirely.

But is there at least some agreement about the potential utility of this concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman@novell.com
1-801-861-7387