Let me try to respond to the issues you raise.
A major point to be made is that, just like PEM, X.509 is an evolving
specification and experience in its implementation is also evolving.
Many (perceived or actual) early deficiencies in X.509 and its
documentation have been resolved, and there is considerable ongoing
work to correct outstanding deficiencies. It is no more valid to
entirely discard X.509 because of deficiencies seen 1, 2, or more
years ago than it is to entirely discard PEM given the same type of
argument. In fact, I believe that we currently have a unique
opportunity to pull PEM-evolution and X.509-evolution together, for
great overall benefit.
A fair point if one buys into the need for X.509 in the first place.
My experience with X.509 (and X.500) is more limited and my
expectations were different. When we got into the PEM design, I took
it on faith that X.509 was mature, and I also took it for granted that
it was established and therefore important. To me, the idea that
X.509 is still evolving tells me we made a terrific mistake having
anything to do with it. Protocols evolve inside the IETF several
times faster than they do inside ISO. Even if the rates were matched
and the processes similar, the difficulties of working within two
standards organizations is simply fatal.
We could have defined a certificate structure comparable to X.509
entirely on our own and been miles ahead of the game. It was only the
promise of the importance of X.500 directories and the apparent
maturity and importance of X.509 that clouded our vision.
The common goal is to see the full potential of public-key
technology achieved, i.e., indefinitely-scalable public-key
infrastructures supporting an unlimited range of applications.
X.509 is by far the best base on which to build such work. The work
is focussed in groups in ANSI X9 and in ISO/IEC.
The same indefinitely-scalable public-key infrastructure could have
been built in a fraction of the time without X.509.
I have lightly scanned the proposals Warwick has communicated. Any
improvement in X.509 is welcome. I am somewhat biased against X.509
because:
o The structuring and encoding add significant overhead and complexity
for otherwise simple things,
This is true, to the extent that it is necessary for an implementor to
use ASN.1 tools. Such tools are now well understood, are available in
the public domain, and are needed for many other purposes than X.509.
The up-side is a well-developed system for specifying and manipulating
complex protocol structures.
o The attempt to impose semantics on distinguished names creates a
huge number of hard cases. E.g. if Professor Farber at the
University of Pennsylvania gives his university address, is that a
personal persona with a business mailing address or an
organizational persona. (And when does it matter?)
I agree that linking semantics to distinguished names is not the way
to go. A distinguished name is just a name - in some cases that name
may be able to positively identify one party to another, but in many
other cases it does not. We are addressing this problem by adding
Subject Attribute extensions to the certificate. In principle, these
fields convey whatever other information is necessary to support
meaningful identification. For PEM, the most interesting field is
undoubtedly RFC822Name. There is also a DirectoryAttributes field
which lets you carry any X.500 attributes the CA is prepared to put
in. Other fields can be registered by communities if required.
o The basic and distinguished encoding rules are incomplete and
ambiguous. The rules for (a) transmitting a name, (b) comparing
when two names are equivalent, and (c) searching for matches in a
database are not easy to understand nor are they consistent.
My memory of the specifics is a little vague, but let me try to
remember the details as best I can. If I've got them wrong, please
correct me. In any case, I know that when we looked closely at this a
while ago, we unconvered unpleasant traps. And I think I should have
enumerated (a) transmitting a name, (b) displaying a name, and (c)
matching a name as the three areas where the rules did not hang
together cleanly.
(a) We went through a lot of trouble with the coding rules. As I
recall, there was more than one way to prepare the binary
representation of a name. I think it's possible to use either
length specifier or a terminating symbol in some cases. This
becomes important because the signature is computed over the
transmitted representation, and thus the transmitted
representation has to be retained in the store.
(b) Although an RDN is supposed to be a set, it was argued that the
order of the elements was important because it represented
additional information the sender wanted to include, and that it
was necessary to display the elements of a multi-element RDN in
the order the originator had chosen. I believe the examples at
the time had to do with various parts of a postal address.
(c) The matching rules made use of ancillary information such as "case
insensitive" for particular attributes. However, it is not
permissible to simply normalize such attributes at the originating
end and demand that e.g. only upper case letters be used. Thus,
if "Van Houten" appears in one certificate while "van Houten"
appears in another, the cases had to be preserved but the matching
rules demand that these be treated the same. This not the same as
having two different people use similar but different
capitalization and trying to build a decent user interface for
finding close matches. As I understand it, it's actually
permitted that the *same* person can have his name capitalized two
different ways. Thus, Ford can issue a certificate to Van Houten,
and van Houten can then issue a certificate to Ellerbee, and the
chaining rules are supposed to be perfectly comfortable with that.
None of these is insurmountably hard to deal with, but it's not clean
and it causes considerably more implementation pain than one would
expect to encounter.
I would appreciate your advice of exactly which aspects of BER, DER,
and name-matching you consider imcomplete or ambiguous. Northern
Telecom has had implementations of ASN.1 and X.500 for several years
which interoperate successfully with other vendor products. I have
little doubt there were/are documentation problems which needed/need
correcting. If there are other problems, they need to be brought to
the attention of the appropriate standards group.
o The rules for adding new attributes are unclear. As best I could tell,
an organization could unilaterally define a new attribute using its
own portion of the OID space, but there would be no way to
communicate the "Syntax" of the OID to others. (I put "Syntax" in
quotes because it's really just a type and has nothing to do with
any normal notion of syntax.)
Yes, any organization can define and register its own attributes.
These are, of course, only useful if the system responsible for the
directory entry and the system which uses the entry have a common
understanding of both the syntax and semantics of the attribute.
Chaining DSAs are required to transmit such attributes transparently,
without knowledge of syntax. You are right that the scope of
usability of privately-defined attributes may be small, which is why
most of us try to stick to standard attributes. However, I do not
follow why this is a problem for PEM.
Adding new attributes was only a problem because the attempt to use
the existing attributes ran into problems, particularly with respect
to email names.
o There is no obvious way to encode an email address if one chooses
that as the distinguished name. The rules for printable string do
not include the necessary punctuation characters.
The v3 extension should fix this.
In contrast, had the PEM standard not been tied to the ISO process, we
could have fixed this problem in real time.
o The documentation is not available online.
Good point. I agree that progress is needed on IETF/ISO collaboration
to crack this properly. In the meantime, informal distribution means
can be used to ensure that progress is not hampered.
Informal distribution? Does this mean we can scan in ISO documents
and distribute them as Internet Drafts?
It comes back to fundamental goals. Creating a PEM
public-key-infrastructure island does not satisfy my goals. I work
with a customer and vendor base which wants to maximally exploit
public-key technology by building indefinitely- scalable
infrastructures which can support unlimited applications, e-mail being
an important one. This means sharing of credentials, end-user crypto
tokens, and certificate management infrastructural products. Broad
acceptance of common infrastructural standards is an essential
ingredient.
All of the functionality of X.509 could have been created easily in
simple ASCII attribute/value structures. The resulting structures
would have been usable for anything, not just mail. And the process
for honing the edges would have been nearly painless.
I don't know what customer and vendor base we're talking about, but I
assume you're referring to some large community of people who live
with X.400 and X.500 based systems. I don't know how large a
community they represent, but we might have been far better off to
treat them as a subsidiary community instead of the center of the
world. PEM -- and other public key applications -- would be
ubiquitous. And the speculation is not merely theoretical. To first
order, the existence and success of PGP makes the point directly. No
wasted effort with X.509 complicated naming and representation rules
and no wasted effort with highly restrictive trust hierarchies.
Steve