[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANNOUNCEMENT: SPKI mailing list and BOF at Los Angeles
> I'll keep this as short as possible, and go along for the ride.
> >I want to say, from the outset, that I really do not believe that
> >X.509 can be "fixed". It has lots of good ideas, but it has ISOisms
> >that are embedded deep inside it.
> Whether that is good, bad, or indifferent depends on what your
> intended applications are, I suppose. Maybe we should come to some
> consensus as to what the problems are that we are trying to solve
> (for which X.509 is allegedly unsatisfactory/insufficient) before we
> jump to such a conclusion.
X.509 can probably be hacked, kludged, squeezed and forced into
solving almost anything. Through a suitable tweak of ASN.1 and enough
pleading to the right ISO committee, I doubtless can extend X.509
certificates as a generalized document markup language, for example,
by inserting the proper hacks into the encoding of one of the strings
that I can plant inside the certificate. However, the wisdom of this
notion must be questioned.
Just as you have mentioned ASN.1 as being better than hand designing
encodings, so I will note that to some, X.509 is unsuitable because of
its cumbersome baggage, regardless of how much it can be forced into
any application that can be envisioned. The issue is not always
One of my major gripes about the ISO process is how, coming out of it,
one has standards that can solve any imaginable problem, but yet which
no one is willing to fully implement because of the gargantuan
complexity of the results. I'm not interested in the question of
whether some possible portion of the requirements space is or is not
covered by X.509. That is not the right question.
Indeed, I must say that I don't see much point in continuing the
discussion of whether X.509 is the right standard. That is a matter of
opinion. Those who have the opinion that it isn't necessarily the
right standard have spoken by forming a group to explore other
options. This group in no way interferes with the existence of the
PKIX group. You are free to try to work with us in this new process,
or to gripe about the fact that we are infidels. If you pick the
latter you are not going to get much sympathy.
> I'm interested to hear his argument, as I do not yet understand the
> concept that X.509 is a "model".
X.509 assumes certificate authorities will be binding unique names to
certificates, with each C.A. key having associated with it a single
certification policy. There are others that have different notions
than binding identities to certificates, like, for instance, merely
binding authorizations, and not doing so from the point of view of
having a small number of authorities, or a small number of
certificates per user of the system. Some have other notions of what
C.A. policies might mean, whether they should be fixed, or even what a
> It appears that there may be two different groups of people who
> would like to discuss these issues -- the virtuous and the unwashed,
> saints and sinners, Republicans and Democrats, etc.
Well, now the question is merely one of who is who, eh?
> >Your experience is valuable and valued by me. I meant it when I said
> >that the input of people with experience both in the X.509 design
> >efforts and in the use of X.509 certificate systems was actively
> >solicited. I must repeat, however, that this isn't the "fix up X.509
> >slightly" group. Starting from a blank sheet, X.500 distinguished
> >names would not naturally arise in an IETF context. Neither would ASN.1
> This seems a little disingenuous. The paper was pretty darned blank
> five years ago when an IETF working group composed of some pretty
> bright people with a lot more Internet savvy than I had picked that
> format for secure electronic mail.
And look at where that format went. Nowhere, fast.
Again, as I've said, this debate can go on, and on, and on, and on. It
will likely not get anywhere. Some of us want to discuss the question
of certificates with a clean start, some of us do not. There are two
different working groups. They have two different charters.
If you are offended by the notion of people discussing these issues,
or you feel it is foolish to discuss them, you are not forced to
participate. If you are worried that the very existence of this
working group is some sort of threat because it might cause market
fragmentation, well, we live in a free society, and more to the point,
the IETF largely requires that working groups have a constituency, not
that they be non-overlapping. I personally do not fear having multiple
technologies or methods in the marketplace of ideas. I do not use a
Macintosh but I am glad that they exist -- many of the systems I use
have benefited from technologies based on those in the Mac. I do not
use Smalltalk, but I am glad of the fact that others do. I do not use
ASN.1 when I can help it, but I am happy that people have explored
part of that design space, for good or ill. Whether the SPKI effort
produces a widely used technology or not, my hope is that it will
result in a valuable exploration of the design space. The best results
are achieved not by trying to stifle innovations but to permit them to
grow or die on their own merits. "Let a thousand flowers bloom." (And
yes, I know full well where the quote comes from.)
And by the way, I really *do* feel that many, many of the folks
associated with PKIX have a lot to contribute to SPKI, but essentially
trying to adopt the same work as PKIX is not our charter.