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?
This is up to Jim, not me. He's the document editor.
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.
My position is quite simple, and I have in fact stated it not once but many
times in postings to this list.
I view a certificate infrastructure as useful but not essential. If I can have
I want to, if not I can live without it. However, I view the requirement that
certificates be used as absolutely unacceptable. And this doesn't just mean all
the PCA/CA stuff -- I'm referring to the any use that requires distinguished
names or certificates of any sort.
I base my position on substantial implementation and operational experience,
where I found that *I* could not get by head around such a structure in a
reasonable amount of time. And this is with an *extensive* background in ASN.1,
international standards, X.400, X.500, and distinguished names. (I have in fact
written commercial implementations of X.400-1984 and X.400-1988 from scratch,
and I have also done porting/support work on commercial X.500.)
Now, I'm nowhere near the smartest or most informed person in the world, but I
know for a fact that I have lots of customers who aren't as savvy about this
stuff as I am. I have to base my work on protocols and standards I feel I can
support. And basic email security services that require X.509 are not something
I feel I can support. It is just that simple.
I had in fact largely withdrawn from this entire effort by the beginning/middle
of last year. The MIME/PEM specification at that time didn't deal at all with
the changes I felt were necessary for PEM to be useful and deployable. And
moreover, I didn't feel that I was the one to make the changes, even assuming I
had the time to learn the necessary details and do the documents, which I
didn't.
It was at this point that Jim and Sandy, undoubtedly sensitive to the signals
they were getting from both their user base and from their coauthor, decided to
take over the document and make the necessary changes. The result is what you
see.
This by itself would not be sufficient to convince me that the new approach is
the right way to go. But Jim also put his development time into coding the new
stuff. This produced a new TIS/PEM, which I decided to try out.
And I was *amazed*. The new TIS/PEM was really slick. It installed easily and
started working without any trouble at all. It was at least as easy as PGP if
not more so. This was a *dramatic* change from my previous experiences with
PEM.
Part of this was due to redesign of the internal TIS structures, which made
porting the thing a lot easier (like less than a week rather than over two
months). But I've also tried TIS/PEM on UNIX systems, where porting is a
non-issue, and the change is still dramatic.
And even with this ease of use, I can still get the cert stuff I need whenever
I want it! This lets me have my cake and eat it too!
This made a total believer out of me. It also solidified my doubts about
the need to use certs from the outset into a certainty that doing so is
a nonstarter, even if you're talking about self-signed certs. Hell, we have
enough trouble getting customers to assign sensible domain names, let alone
distinguished names!
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?
I have no objection to self-signed certificates. What I'm opposed to is the
removal of the other mechansisms from MIME/PEM that let you operate without
having 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 understand this. However, I don't think self-signed certs are a useful
form of bootstrapping
Now, I could be wrong about this. But allow me to point out that this whole
self-signed cert business is a new solution that has only recently been
proposed. If we're to run with it we're going to have to make some changes to
the RFC1422 model. (It may not be a divorce, but its at least a trial
separation.) Without these changes MIME/PEM doesn't even allow self-signed
certificates. And since this is exactly what is being proposed, I don't
see that your needs are met by this proposal either.
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.
I disagree that self-signed certs are the most appropriate mechanism. I
think the most appropriate mechanisms are what MIME/PEM provides.
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.
The history of this working group speaks for itself on this point. Frankly, I
think a year is an optimistic estimate.
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.
You have it backwards, I'm afraid. I was vague and inaccurate before, but I'm
labelling things accurately now. You want to get the v3 cert stuff done, and
that's fine -- I have stated numerous times that I think this is a good thing
and that I will support it. But for some reason you feel that it cannot or will
not happen on its own, so you are making your support of MIME/PEM conditional
on the inclusion of the v3 cert format so you can leverage off the support for
MIME/PEM to get your v3 cert format.
It isn't clear to me whether this is because getting documents through this
group is like pulling teeth and you want to avoid that, or because you want to
leverage off of MIME/PEM deployment requirements to get support for v3 certs
out into the world. I sympathize with the intent either way, but sympathy
doesn't change my position here.
In either case, however, I believe that calling it portbarelling is accurate.
I'm sorry if this label offends you, but that doesn't make it incorrect.
Let me flip this around and you'll see what I mean. Suppose I say that I'll
support the use of v3 certs only if you agree to the MIME/PEM document plus v3
certs IN ADDITION to all the other non-cert mechanisms. What would you say to
that? You'd call it porkbarrelling, and you'd be right to call it that.
The matter of your affiliation with one group or another is entirely irrelevant
as well. I don't know and don't care whether or not you have personal,
professional, or financial reasons for wanting the v3 cert format included.
That's not relevant. What is relevant is that this is a separate piece of work
and therefore should be done separately, and you don't want it done that way.
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.
But you are delaying things unnecessarily by starting this effort now and
making the completion of MIME/PEM contigent on it!
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.
Let there be no misconceptions about my intentions here. I have to have
something and it has to be soon. The one thing I can say for sure is that it
won't be classic PEM -- I tried that and it fell flat. It may be the current
MIME/PEM specifications without IETF approval -- we can always publish MIME/PEM
as an informational or experimental RFC without this group's approval. Or it
could be PGP. I haven't decided yet, and I won't do this alone anyway -- I'll
enlist the aid of others who feel the same way about this as I do.
Once a decision is made, however, I will do my best to promote its virtues far
and wide, and I will try my best to get other developers to support it,
no matter what this working group produces.
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.
I'm amazed that you could say this given some of the postings to this group
over the past couple of months. While it is true that there has been
considerable discussion that has been reasonable, informed, logical, and
useful, there has also been a lot of stuff that was grossly incorrect or
distorted, unreasonable, illogical, mean-spirited, and downright ugly. If you
want a specific example, the statement by our working group chair that our
documents had been called "shit" by some unnamed member of the IESG stands out
above the rest.
As for disagreeing with me, well, I have no problem with that. Disagreement is
good. But that's not what is happening here (at least it isn't the primary
thing that is happening here).
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.
Bob, I don't think (and have never said) that you are intentionally using these
discussions as a delaying tactic. However, I also believe that "results
achieved are usually the results intended". And in any case, the fact
remains that we are very very very late here, and it is getting later.
Ned