Ned,
It seems that you and Jim are determined to throw down the gauntlet. I think
this is truly unfortunate, and deeply regret if I have done anything at all to
bring us to such an impasse.
I will therefore bite my tongue and not reply in the same spirit, however,
since you indicate that there have been numerous chages to the existing
document. It is possible that those changes will remove some of my objections,
and I will give you the benefit of the doubt and wait for the updated version
to be published. When can we expect to see it?
However, this sounds to me like a proposal that we do away with all forms but
those based on certs. This is not acceptable to me, as I've stated in a
previous message.
There have been lots of messages that have flown by, but I have commented to
several people that I truly didn't know what your position was on that
particular issue. I would be more than happy to carefully review your position
and see if it would alter my thoughts on this subject, before we end up at an
ugly impasse that would serve no one's best interests. Would you therefore
please restate your objections, and perhaps amplify on them? I still have an
open mind.
As far as key selectors go, they are not a big concern for me either way. I
think they are nice to have and the difficulty of supporting them has been
overstated, but I can live without them. What I cannot live without is some
alternative to the cert model.
I want to make absolutely sure of the nature of the disagreement here. Are you
saying that you are opposed to the introduction of an alternative form or
mechanism for implementing the direct trust model, e.g., through the use of
self-signed certificates? Or is there some other point that I have perhaps
missed? Onm the other hand, is it possible that you could have missed my often
stated agreement that some means of bootstrapping the deployment of these
systems is required, prior to (hopefully) a more comprehensive deployment of a
a nationa or international public-key infrastructure? I don't pretend to speak
for anyone else, but I have repeatedly agreed with that position, and am only
arguing the most appropriate mechanisms to be used.
As I said before, the current draft does NOT reflect the current document,
which has undergone literally hundreds of editorial changes. I therefore think
this is a waste of time no matter what.
OK, that's fair. Let's wait for the next release before burning any bridges.
I STRONGLY OBJECT to the inclusion of v3 certs as part of this work. Doing so
guarantees a delay of at least another year, in my opinion, which is not
acceptable to me. It is also objectionable on procedural grounds -- this is
standards porkbarreling and nothing more.
Althouhg I would very much like to see v3 certifi9cates included, for the
reasons I have stated, that is not my highest priority. I think it would be a
shame and a lost opportunity, but if there is the slightest chance that this
would in fact delay ANYTHING AT ALL by a year, or even six months, I would
agree with you.
I do however most strongly object and take personal offense to the derogatory
phase, "standards porkbarreling." As I have been one of the more vocal
advocates of this recommendation, I have to assume your comment was addressed
to me. I am not a member of the X.500 standards group, nor of X9 which has also
been involved, and I have absolutely no financial or personal interest one way
or the other in the adoption of this standard. I am quite certain that if you
check back in the PEM archives in 1993 or even 1992, you will find that this
suggestion originated with the PKCS efforts when they grew impatient with the
lack of progress in the PEM community in addressing some of the various issues
that you yourself have raised. It was developed further, and in public on
pem-dev as opposed to the rather closed discussion that produce the PEM/MIME
spec, by discussion between myself, Rhys Weatherley, Warwick Ford, Hoyt
Kesterson, and others that I may have forgotten. People in at least three
different countries were involved, and no more than one per individual company.
It is therefore difficult to imagine the kind of smoke-filled room kind of
conspiracyt that you are implying. If you can't be accurate, at least try to
avoid being offensive.
If you want to prove me wrong you have only to produce a completed
specification of v3 certs that defines them adequately and deals with all the
issues they raise. This has to be done in any case -- so by all means get
started. Of course I'm unaware that anyone has volunteered to do this, let
alone begun to assess the task...
I did in fact volunteer to try to do this, hopefully with the assistance of
Warwick and Mark, although I have other professional and personal obligations
that make this rather difficult. If during the performance of this effort
insurmountable obstacles begin to appear, I will be the first to recommend that
we shift the effort to another venue, such as updating RFRC1421, so as not to
delay the PEM/MIME spec one millisecond. I think I already said as much in a
previous message.
These proposals would, I believe, allow us to reach immediate closure on
those issues we are *not* arguing about, and open up the scope usefully on
the issues we *are* arguing about, most of which apply just as much to
RFC 1421 PEM as they do to MIME/PEM.
As I said before, if this means what I think it means I have no interest in it
and will withdraw from the MIME/PEM effort entirely. I probably will take
steps
to shut down all PEM development work at Innosoft as well, since I think that
cert-only PEM is a nonstarter now and always will be.
This is not intended to be a threat -- most of you do not and should not care
what Innosoft does or does not do with PEM. However, I feel that it is only
fair that I alert the group to my intentions in this area. I will also
recommend that other email developers do the same as Innosoft.
And let there be no doubt about my authority here -- my position at Innosoft
is Chief Development Officer so this is my call to make. As a practical matter
it has been an uphill struggle to get Innosoft to devote any resources to PEM,
so this will not be at all difficult to accomplish.
You are correct. Although I believe that this would be an unfortunate turn of
events, the issue of whether a standard should be supported or not should not
depend on whether a given company chooses to implement it. I'm sure that your
technical contributions would be sorely missed in this area, but if there is
any vitality in the area at all, the presense or absence of one individual
shoudl not matter that much - you, me, Steve Kent, Jim Galvin, or anyone else.
al;though I would very much like to see security integrated with MIME, I have
to confess that MIME is not nearly a burning issue with me as it is with you,
but I am more than willing to agree that this may reflect differences in the
community with which we communicate. I would very much like to have a
version of PEM/MIME, but not if it irrepairably poisons the well for other
applications, and that is my concern with the use of a variety of not very well
thought out alternatives (IMHO) to certificate-based systems.
BTW, for what it is worth, I sympathize with you and your difficulties in
getting your management and peers to devote the kind of effort to PEM and
related subjects that you have obviously invested, and the same applies to
Amanda, Jim, and others as well. this area is difficult, and security is often
a very tough sell. At least you presumably have the opportunity to recoup your
investment by selling new products. On the other hand, I seem to be in the
position of trying to help raise the entire industry in this area, in the
perhaps vain hope that it will lead to an increased awareness of and use of
data services, and perhaps thereby increase the number of residential and
business telephone lines, ATM, frame relay, ISDN, or other services offered by
my corporation. Would you like to trade positions?
I feel compelled to say, however, that it will be a relief not to be caught
in the middle where I have to defend the actions of this group to my
peers at Innosoft and elsewhere as being in some way logical or reasonable.
That seems like rather a cheap shot, considering that you have the same
opportunity to voice your concerns as anyone else, and in fact have not engaged
the rest of the group in very much discussion on these issues, whether
reasonable or not, prior to the middle of December. We may disagree in our
assessment of the facts and requirements, but I haven't observed anyone making
wildly illogical and unreasonable observations, unless you mean by that anyone
who dares to disagree with you.
But let me close on a more conciliatory note, and hope that it is not yet too
late to effect some kind of a compromise. I don't make any pretext of
representing anyone's viewpoint other than my own. I owe no allegiance to
anyone else, and certainly no one owes no allegiance to me. I'm perfectly
willing to have the unseen lurkers on this list, probably numbering in the
thousands if not tens of thousands, rise up with one voice and shout, "For
God's sake, Jueneman, SHUT UP! No one is supporting you, and no one cares what
you think." Until that happens, however, I will continue to listen to your
arguments,politely comment, and hope that you will listen to mine and others,
in the hope that we can eventually find some middle ground that is mutually
acceptable. But you don't have to -- you can pick up your marbles and go home
and sulk, or you can go ahead and ship your system as it is presently
described, and let the marketplace decide. No one is stopping you, one way or
the other. But please don't describe my objections to some kind of unworthy
delaying tactics -- I don't care whether you ship your system or not, or when,
and I have absolutely no reason to try to delay the inevitable, if it comes to
that.
Cordially, I hope,
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820