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

Re: ANNOUNCEMENT: SPKI mailing list and BOF at Los Angeles

Perry, I admit to some ambivalence in joining this discussion. On the one hand, 
I am greatly concerned that an attempt to open a "second front" in a public key 
infrastructure will be divisive, contentious, and confusing to potential 
vendors and end-users alike. On the other hand, if there are legitimate issues 
that people feel cannot be adequately addressed by the existing X.509 
certificates, I'd like to understand them and fix them.

>I will say from the outset, however, that I doubt, starting from
>scratch, we would have ended up with X.509; the reason being that
>things like distinguished names and ASN.1 would not likely be things
>the internet community would adopt. However, that said, I'm very much
>interested in hearing the contributions of people with experience in
>the X.509 world and in hearing from those who advocate producing an
>X.509-like system with a much simpler encoding and a more IETFish
>naming structure. It may be argued that X.509 is the global standard
>and that the world doesn't need two standards, but then again, the
>IETF has a habit of trying to stick to technical merits and not
>political ones.

I'm never quite sure who the "we" is, or exactly who the "internet community" 
is. but I'm not sure that I would agree with you. You seem to feel that X.509 
was somehow foisted upon the Internet by some external forces, but that simply 
wasn't so.

In 1987, nine years and three companies ago, while I was still with CSC, I 
built one of the first, if not the first, secure e-mail programs to use public 
key cryptography. It was called STAMP -- Secure, Tamper-proof, Authenticated 
Mail Program. The work was motivated by the recognition that existing key 
management doctrine (based on symmetric keys, e.g., X9.17) wasn't going to cut 
it in a very large network composed of sometimes cooperating and sometimes 
mutually suspicious user domains. It used 384 bit RSA keys and single DES, and 
by today's standards its cryptographic strength would be considered pitiful.

It didn't use X.509 certificates -- I don't know that they had even been 
invented then, but certainly I hadn't heard of them. But it did support a 
hierarchy of digitally signed "authorizations" that looked a lot like a 
certificate. It even supported cross-linked hierarchies, because one of the 
common modes of operation for us at CSC was to team with another company for 
one proposal, but compete against them on some other bid. It seems funny that 
we are just now coming around to those kinds of concepts in X.509 V3. And even 
back then, I was very concerned about trying to put this infant technology on a 
sound legal footing, so that it would be used for electronic commerce, as well 
as for privacy of communications. so we had digital signatures for 
authentication, an Affidavit of Legal mark that was intended to address the 
issue of whether a digitally signed document was legally binding, etc.

I'm just saying all this in the spirit of "been there, done that."

In retrospect, that early prototype suffered from several problems that 
probably would have been fatal flaws had we tried to develop it into a product. 
(This was an IR& D project, and at that time CSC didn't develop or market 
products.) 

First of all, we didn't pay adequate attention to trying to ensure that the 
person who was represented in the certificate was uniquely identified. I don't 
recall the details any more, but I seem to remember that we had a name, a 
company affiliation, and a street address -- pretty common stuff based on a 
snail mail view of the world, primarily.

Second, although I knew better, we didn't have any kind of object-oriented 
design or strong typing of the different kinds of attributes. They were all 
just hard-coded in a structure, so only the compiled code could know which 
fields meant what. Even during the development and debugging that began to be a 
nuisance, for it was difficult to make revisions in the structure without 
impacting everything else -- and we only had three or four people working on 
the project.

And third, I didn't put much thought into how to actually distrubte the 
"certificates". If I had, I would have been more concerned about question of 
indexing, what kid of data was going to be included in the index, and how 
people would browse he directory to find someone's certificate if they didn't 
already have it.

Gee, isn't that funny -- those seem to be precisely the issues that we are 
still facing, even in this new forum!

You may or may not like the geopolitical naming scheme that is often cited as 
an example of a distinguished name in X.500, but I would contend that if you 
want to communicate securely with someone and you don't have the luxury of 
having that person physically hand you a disk with his public keys on it, then 
you had better be pretty sure that he is who you think he is, and not one of 
the other 23,000 William Smiths in the US. Likewise, if you are going to honor 
or trust his digital signature for anything important, you would want to know 
exactly who that person is as well.

So if you want really good privacy, and trustworthy digital signatures, you 
have to solve the problem of uniquely naming/identifying an individual in a 
manner that is repeatable. I don't care what you do -- you can use a person's 
postal address, or a world-wide telephone number, or a has of their birth 
certificate, but you have to come up with something that is globaly 
unambiguous. And once you do, you have just created a distinguished name. All 
that's left to argue about is the schema that is used, and how easy 
(user-friendly) it is to browse a directory or database containing such 
information.

The issue of strong typing and identification of attribute fields isn't 
something that comes naturally to a lot of programmers who are either still in 
school or just out of school, primarily becasue they haven't had enough 
experience working with very large systems that must be supported and 
maintained over a very long time, by many hundreds and sometimes thousands of 
people. When you are only writing code for your own personal use, using some 
kind of an attribute-value notation seesm lke a lot of needless effort at the 
time. But experience shows that sooner or later, the investment in the 
infrastructure will pay off down the line.

A lot of people don't like ASN.1. It isn't terribly easy to read, there aren't 
a lot of high quality compilers lying around that are free (like a lot of other 
things in life), and some of the purists would argue that like a lot of 
standards, the people that designed it didn't know when to quit. OK, let's 
stipulate that. So what's your next choice -- COBOL? Certainly a lot of the  
"Internet -way" standards seem to have been written by people who afraid to 
ever represent anything in binary -- they'd rather parse a bastardized, more or 
less human readable string. The point is that even if you admit to the faults 
that people criticize ASN.1 for, it's still better than any other even 
reasonably popular metalanguage. There are free compilers available (and worth 
every penny you pay for them), and there are also commercial-quality compilers 
that are excellent. And if you don't like either of those choices you can view 
it as a specification language and develop your product using hand-coded 
assembler language. (Reminds me of the "Real men don't use compilers" argument 
of 20 years ago. And 30 years ago it was "Real men don't use assemblers, they 
write it all out in octal, and punch it into paper tape.")

So if this group is just going to go on an anti-ASN.1 kick, count me out. We 
are too close to having a real concensus emerge on an X.509-base public key 
infrastructure to spend all of the time and effort debating that point again. 
We went through it all back in the PEM days -- look in the archives. Even if 
you can't stand the thought of ASN.1, introducing a completely different 
encoding scheme would have to have almost overwhelming advantages to make it 
worth the bother of having two different and incompatible kinds of certificates 
formats at this point in time.

Likewise, if people want to argue that there really isn't any purpose in havng 
some form of globally unambiguous naming information, whether based on e-mail 
addresses, geopolitical/organizations hierarchies, or a number tatootted on you 
at birth, I can't help you much, for such systems would simply not be 
sufficiently reliable in a global village environment to be very useful.

I suspect that the biggest beef that most people have with X.509 is that they 
don't like what they perceive to be the constraints placed on them by the 
Distinguished Name. And I will assert that 90% or more of that argument is 
based on a misunderstanding of what a DN really is, and how much freedom there 
is to create alternative DN structures.

So if people have problems that they feel can't be accommodated by the existing 
X.509 structure, I'm more than willing to listen, because I believe that those 
problem are more imaginary than real. Of course you may not be able to find a 
Certification Authority that will go along with you view of the world, but you 
could always set up your own CA and see how many people beat a path to your 
door.

>Beyond the X.509 model, I will point out that there are advocates of
>radically different models present, who don't like the underlying
>principles on which X.509 is based (like binding identities instead of
>roles). I want to hear from them, from people who would advocate that
>we simply adopt the mechanisms in the DNS security work, and from all
>other points of view.

I don't understand what is meant by "the X.509 model". X.509 isn't a model of 
anything -- it's just a certificate. I believe that people confuse X.509 with a 
certain view of X.500 (which generally isnt' correct), or even with X.400. 

However, if people believe that there are _inherent_ problems with X.509 and 
its ability to represent a very wide range of naming and identification 
schemes, including role-based schemes, then I would be interested in hearing 
that point of view.



Bob

Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Jueneman@gte.com
1-617/466-2820

"The opinions expressed are my own, and may not 
reflect the official position of GTE, if any, on this subject."
Follow-Ups: