Ned, your later message indicates that some of your comments should perhaps be
ignored, but I'd like to ask a couple of questions.
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.
I have not tried the new TIS/MIME/PEM, in part because the problems I had in
installing the trying to use the previous implementation. I'm glad to hear your
reaction, however, and will try to find the time to try it again.
However, this very reaction tends to underscore my feeling that it may not have
been PEM that failed to win acceptance, but rather the particular reference
implementation. That's admittedly an over-simplification -- I'm not trying to
deny the complexity in setting up the traditional style of DNs and hierarchical
certificates, especially when at a time there were a lot of growing pains in
setting up the PCAs and CAs. But I don't think that was the only reason.
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.
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.
You may have a valid point here, at least from the standpoint of the RFCs.
Although Jim and Steve Crocker have described their implementation of
self-signed certificates, it is clear that was an implementation extension
beyond RFC1422. Whether those RFCs PROHIBIT such usage is a different question.
I don't think so, but it is worth a look. I'll certainly grant that they don't
support or describe such an approach, but I think that was considered a "local
matter".
Unless such usage is specifically prohibited (and I doubt that it was, or Steve
and JIm wouldn't have implemented it, or at least would have screamed), I don't
see why you would say that MIME/PEM wouldn't allow it. The concept of keeping
some features while discarding others in 1422 doesn't seem to have constrained
you from offering other forms of certification, so this should really be pretty
much of a non-issue.
The notion of self-signed certificates originated with one of the early
proposals for implementing certificate generation through the use of a
co-issuer, where the user would create a self-signed certificate and transmit
it to the certificate issuer or to an organizational notary. The purpose of
having him sign the certificate was to ensure that he really possessed the
private key corresponding to the public key he was attempting to bind with his
identity. This goes back two, maybe even three years or more.
The broader use of self-signed certificates as an alternative to PGP and/or a
way of bootstrapping these systems cam up in late 1993, as I recall, through
discussions that I believe that Rhys Weatherley originated.
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.
I'm afraid I muddied the water by my "Horse-trading" proposal. At the time, I
thought that if we could get v3 implemented in the near term, the usage of the
non-certificate based systems would wither and die, and therefore my objections
to those fomrs would become moot. Maybe that did constitute porkbarreling or a
suggested political compromise, and if so mea culpa. I was really just trying
to offer a possible compromise and get the effort off dead center, where no one
was moving anywhere.
At this time, therefore, I would withdraw that suggestion or offer, as it seems
inappropriate and perhaps counterproductive. Progressing PEM/MIME to a
standards track should not depend on implementing v3, and implementing v3
should not depend on PEM/MIME, although PEM/MIME might be the next horse out of
the chute and therefore of the greatest interest to me. Although I continue to
believe that you are overstating the difficulties in describing and
implementing the bare-bones v3 capabilities, some of the problems I observed
with the CRITICAL flag when applied to CRLs indicates you might have a point.
So the discussions should best not be linked, but evaluated independently.
(See? I can change my mind too! Maybe there's hope for all of us!)
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820