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

Re: one possible motivation for X.509 -Reply

I can't stand it. Let me correct the record before any more of this nonsense
becomes part of the folklore.

>>> Rich Sal <rsalz@osf.org> 07/18/96 07:58pm >>>
PEM died because it required a global X.500 directory and we'll never
have that.


PEM never required a global X.500 directory. It was intended to take advantage of
and interoperate with one if one came along. Since X.500 was a standard, and at the 
time, at least, seemed to have a fair head of steam behind it, that seemed like a prudent
course. After all, such stalwart Internet techies as Marshal Rose were working actively
with the NADF and trying extend the Paradise project and other initiatives to make X.500
a reality. But we explicitly recognized the risk, and therefore did NOT build in any 
dependencies on X.500. Coexistence and cooperation, yes.

With regard to the X.509 distinguished name, there was explicit recognition that the DN
in the certificate did not have to conform to the schema of any particular X.500 directory,
nor did X.500 even have to exist.

PEM failed, in my judgment, for three important reasons:

1.  As a bunch of technologists, including some extremely bright folks like Steve Kent
who had worked on equivalent systems for DOD, we tried to model a system we didn't
quite understand -- commerce, and the law.  I believe that most of us felt, rather naively, 
in retrospect, that if we could just had a very good way of establishing who signed
something, and nailing that signature to a claimed identity, that individuals could buy and sell
things, send secure e-mail, etc., without regard or need for intervening institutions. In 
retrospect, it didn't really occur to us that the signature on the check is far less important
than we wold like to think -- the only thing that matters is whether there is money in the account.

With regard to the distinguished name itself, I had the same wrenching experience that Carl did.
Despite having built working systems, and negotiating with RSA for a year or so to become 
one of the very first CAs (never happened), when I finally took the Memorandum of Understanding
to GTE Laboratories' legal and finance folks, I learned some important lessons. The first was about
intellectual property rights, and the exceeding importance that large corporations attach to their 
corporate name and trademarks. The second concerned the importance of corporate firewalls and 
the flow of liability in large corporations, especially ones that involve separate regulated utilities
doing business using different names in almost every state. And the third concerned the power of 
corporate officers and agents, and what it takes to be able to commit the corporation (or avoid
committing the corporation).  (BTW, I don't mean to imply that GTE was wrong, paranoid, or 
overly concerned about these issues. I just didn't understand them. Fools rush in...)

(Of course, Carl was there all along, saying that names and legal entities didn't matter, that all that 
mattered was the public key. But that was because Carl was (and still is) trying to solve a different 
problem than the rest of us were -- one that is a lot closer to Kerberos and its model of capabilities 
and granting of tickets of authority, etc., than to the existing model of business practices that have 
evolved over the last 100 years or so. Not that Kerberos model isn't a worthwhile problem in its 
own right, but it wasn't (and isn't) the problem the rest of us were as interested in.)

Since those early days of PEM, the ABA Information Security committee has labored (sometimes 
VERY labored:-) to produce the necessary legal underpinnings to support the concept of a digital
signature in a legal sense, and perhaps more importantly, to explicitly address the issues of 
allocation of risk. We now (10 years after I first proposed an "Affidavit of Legal Mark" approach
to addressing some of these issues) have four states that have passed digital signature legislation.
Two, Utah and Washington, have made a valiant if as yet imperfect attempt to address all of these 
issues, and two others, California and Florida, have said basically that digital signatures are OK and 
we'll let the lawyers fight over the distribution of risks.

So in my judgment, PEM didn't fail -- it was just premature. As a standard, it was (and still is) a 
perfectly decent effort. If the TIS model implementation was a little bloated, well, we got what we 
paid for. It was never intended to be a commercial-quality product.

Perhaps more to the point, the lengthy discussions and legal epiphanies that occurred during the five 
years or so that PEM evolved contributed directly to the recognition of the inadequacy of X.509 V1,
most especially the recognition that all the various problems we were having with the DN were 
caused by the fact that there wasn't any other place to put useful information in the certificate
other than the DN, and as a result the DN became overburdened with name subordination rules, etc.
I can't fault the original designers of X.509, who were using it to provide strong authentication to the 
directory itself, and the directory had lots of other places to put the information. But the result was 
X.509 v3, and although it could certainly be argued that the various extension are now pretty complex,
it isn't expected that all of those extensions would be used all of the time -- they are there to support an
extremely wide diversity of potential applications, as people like Peter Williams could attest.

The second reason why PEM failed, if it did, was the direct result of the lossey-goosy 
collaboration that we call the Internet Society, and they way that the IETF works. Although a 
number of people recognized that  global hierarchy of CAs could not possibly provide a common 
semantic basis for trust, it was thought important to provide at least a common root for a 
syntactic validation of a digital signature, and a place to anchor CA policy statements, i.e., 
the Internet Policy Registration Authority. There was also a rather vague hope that since
 the various states had not stepped up to the job of acting like a name registration authority,
perhaps the IPRA would be able to at least detect collision in the name space of residential a
and anonymous users.

Unfortunately, establishing the IPRA meant that the Internet Society and/or the IETF 
had to do real work, and undertake real responsibility, i.e., act like a real business. That, I
claim, it is not well constituted to do, and if it were, it would start behaving a lot more 
like ANSI or some of the other organizations that this community sometimes likes to throw 
rocks at. Without intending to blame any particular set of people, I think it is fair to observe that 
the IPRA was too little, too late, and never really solved the problem.

The third reason why PEM failed, in my opinion, was the creation of a splinter group that 
set about to "fix" two things they claimed were "broken" with PEM. One was the fact that 
it didn't support MIME, which by the time the PEM standard had been finished had begun 
to be an important force. In this effort, people like Ned Freed did a commendable job. 
Unfortunately, those folks have not yet been successful in convincing the commercial 
purveyors of e-mail systems to adopt their approach, even though I personally believe 
that it is superior to S/MIME. The other thing that was allegedly broken was PEM's use 
of a hierarchical tree of CA's. Maybe it was broken, or maybe the reference 
implementation was just too ungainly and lacked support for multiple trusted 
("root") keys. 

In any case, a new direction was established,. Unfortunately, all that the 
new effort produced was confusion within the various commercial e-mail 
developers organizations, and a big "let's wait and see which one wins" 
attitude. The net effect was similar to the effect that Ross Perot had in the 
last election -- he split the Republicans, and let the Democrats win.  

I think there is a lesson to be learned there, but it doesn't have anything to 
do with ASN.1, or with X.500.

"The nice thing about standards is that there are so many to choose from."