Because of some family medical problems, I have not been able to devote the
time I would have liked to reading the most recent drafts. The fact that they
are sent as signed multipart MIME enclosures, which none of my available MIME
readers supports is a minor inconvenience, but one that has kept me from at
least scanning them as they came in. At this point, therefore, I don't have
either criticism or praise on the technical front. My concern was that the
specs seem to be evolving rather quickly, but somewhat in a vacuum by
comparison to the previous efforts.
Your explanation of the process was quite reasonable, and in fact I
commend TIS for putting their own money (as well as ARPAs) into a
implementation reference, whether or not it conforms to the latest
concensus. My only concern was whether the process was creating my
problems than it might be solving, by leaving the entire community
up in the air as to the direction we were taking.
I had thought we had been pretty clear about the direction of the
effort. Previous versions of the specs had been distributed via
pem-dev, and the current spec is not all that much different.
In any case, the specs are on the table, the implementation is
available, and the process is in the hands of the working group and
the IESG.
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.
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.
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,
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?)
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.
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.)
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.
o The documentation is not available online.
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.
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.