Steve:
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.
With respect to the general issues of trust models, addressing
issues, etc., the passage of time plus some of the work I have been
doing within the NADF and the ABA group on certification authroties
has convinced me that a pluralistic approach is necessary to
accommodate all of the various interests.
Great! This is, in my opinion, the most important conceptual issue
that has faced us.
Sounds like many of us are in agreement on this.
I want to address some of these issues in more detail in a separate
message, but I wonder whether you are up to speed on the various
modifications and enhancements that Warwick Ford has proposed for an
enhanced X.509 certificate, and whether you feel that those
extensions would solve some of the problems that you have previously
identified.
Thanks Bob, but you give me too much credit. This ongoing work is, in fact,
the
result of contributions of several people representing computer/comms product
vendors, plus a broad user community. 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.
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.
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.
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.
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.
All in all, I found the X.509 structure quite out of synch with the
usual mechanisms and tools we use on the Internet. I didn't start out
with such a negative view; a lot of hard work went into discovering
how difficult it was to get it right and how ragged it all is around
the edges.
I believe the edges are being systematically honed as time passes.
Aside from the deep divisions among is with respect to trust policies,
I believe we have all paid an enormous price for the attempt to live
with X.509. It was a well motivated attempt, and I suppose we're
bound to continue on this path, but I'm not persuaded that the
definitions and craftsmanship of that body of work is significantly
better than the more traditional work we're accustomed to in the IETF.
All that having been said, any improvements Warwick or others can bring
to X.509 will be welcome. As I said, we're undoubtedly bound to deal
with X.509 forever, so we might as well make the best of it.
Steve
P.S. To compound the heresies above, let me note that one way to
simplify the MIME-PEM spec is to eliminate all use of X.509
certificates. The same effect can be achieved by using a structured
MIME body part, e.g. application/certificate, which would contain
nothing more than the Subject's name and public key and whatever
ancillary information such as expiration, etc. It could be an
open-ended structure with potentially additional elements such as
authorizations and capabilities. No additional mechanism would be
needed for the Issuer's identity or signature; the Issuer would only
need to sign the body part. This entire idea would be implemented in
an afternoon if the basic signature mechanism is in place. These
forms of certificates would be easily parsable and manageable on all
existing platforms without additional tools. They would also be
completely transmittable via mail without special encoding.
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.
Warwick