[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANNOUNCEMENT: SPKI mailing list and BOF at Los Angeles
Perry, my primary interest in all this lies in understanding the various
applications that people have in mind, and exploring whether a reasonable
accommodation can be made between an infrastructure which I expect will be
widely deployed by the end of this year, vs. a new "optimized" approach. Maybe
it can, maybe it can't. So far, I've heard more solutions than problems.
I understand that market forces can be wrong -- the ongoing debate in the
high-end home theater community regarding Dolby's AC-3 vs. the DTS system is a
good case in point.
On the other hand, because I am interested in seeing _some_ kind of a public
key infrastructure deployed successfully, I am hopeful that some accommodation
can be found so that we don't fall into a Beta vs. VHS, or 45rpm vs. 33 rpm
battle. If you look at what has happened with HDTV, for example, the various
warring factions have so far managed to almost kill it off.
>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.
The point that I am trying to make, is that I don't believe that X.509 needs
ANY such hacking, kludging, squeezing, or forcing to be quite suitable for
99.9% of the various end-user applications I know of, including a number of new
applications with new and previously not-understood requirements. I believe
that the extension of the basic X.509 capabilities to handle the MasterCard and
Visa application is an excellent case in point. Here is a worldwide application
that will ultimately touch millions and perhaps billions of customers, that
will be supported by all of the major web browser and server vendors, will
operate in over a hundred countries using several dozen languages. Yet the
MasterCard specifications were written in about a month and made extensive use
of ASN.1, both in the basic protocol itself and well as in X.509. The ability
to define addition private extensions was already provided, and we took
advantage of them. when we realized that ASCII wasn't going to cut it with
respect to even our French-speaking Canadian and Spanish-speaking Mexican NAFTA
partners, it was a simple matter to substitute BMPString and move on.
>
>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.
I would buy that with respect to X.400, and perhaps arguably with respct to
X.500, although at last count there were several dozen X.500 implementations
available. but I absolutely cannot buy the gargantuan complexity of X.509. It
simply isn't that hard.
>
>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 have no intention of proclaiming anyone to be an infidel, nor in interfering
with what you are attempting to do. You certainly have the right to start a
mail list, and to convene a BOF to see if there is sufficient support for
forming a work group under IETF sponsorship. Whether such support will develop,
and whether such a group will make good progress in defining an RFC and
advancing it through the standards process will take time to determine. I just
want to make sure that people aren't going off and pounding their heads against
the wall because of an incorrect understanding of how X.509 really works, and
how it is being implemented.
But enough of the religious argument. Let's get back to the application
requirements.
>
>> 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,
X.509 binds a distinguished name (an index into a database, primarily),
together with other information that can be extended more or less arbitrarily,
to a public key. So far so good, although proposals have been made to include
more than one public key (rejected for the sake of simplicity.)
>with each C.A. key having associated with it a single
>certification policy.
Whoops! Not true. Cross-certification allows a single CA key to effectively be
certified under multiple CA policies, and I have no doubt that this will happen
after the CA industry goes through the inevitable "my policy is better than
your policy" market discrimination bit.
There are others that have different notions
>than binding identities to certificates, like, for instance, merely
>binding authorizations,
That is basically what MasterCard and Visa have done. There is specifically no
identity information in the certificate at all, just an arbitrary serial number
to ensure uniqueness.
>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.
I don't think that anyone is presently contemplating only a small number of
authorities, although that may have been the view several years ago. If there
are on the order of 100,000 busness in the US, I would expect at least 10,000
CAs for internal use alone.
And although it might be nice to consolidate some of these certificates from a
key management perspective, I expect to have at least as many certificates in
my electronic wallet as I currently have pieces of paper in my leather wallet.
(I might not carry my wife and daughter's picture, nor a bandaid or two,
however.)
Some have other notions of what
>C.A. policies might mean, whether they should be fixed, or even what a
>C.A. is.
Since very few CA policies have yet been published, I would say that the jury
is still out. But do you mena fixed as opposed to broken, or fixed as opposed
to dynamic? In any case I am particularly interested in your thoughts on these
usbjects, and I believe they have nothing whatsover to do with the certificate
encoding question.
>
>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.
Since I only recently subscribed, maybe I missed the charter. Has a formal
charter been presented and agreed to by most of the list memebers?
>
>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.
No, not at all.
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.
Yes, I admit that is a major concern. It has taken a long time and a lot of
hard work by a lot of people to get us to this point, and I am frankly
concerned about the confusion factor that may result. If the results can be
demonstrated to be truely superior, then perhaps it will be worthwhile, but all
too often the better is the enemy of the good, and it becomes time to shoot the
designers and build the damn product.
>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.)
I'm all for that. And I would suggest that a rational way of exploring that
design space would be by posing a set of sample application problems, and then
seeing how various alternative solutions would handle them. So far, I haven't
heard either the applications or the alternatives, but maybe I am just being
premature.
>
>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.
>
>Perry
>
Fair enough. I feel confident that if the SPKI group comes up with some valid
problem definitions, the PKIX group will be forced to address them, and that
will be healthy. And vice versa, perhaps if the SPKI group is forced to clothe
the emperor by some of the counter-arguments, that recognition will be healthy
as well.
Two hands clapping are effective. One hand clapping and then the other hand
clapping doesn't accomplish much except moving the air around.
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."