pem-dev
[Top] [All Lists]

Recommendation to proceed to Proposed Standard

1995-01-17 20:46:00
Amanda,

Maybe it took a woman's touch, but you have finally convinced me to recommend
that we progress draft to Proposed Standard. I am clearly not thrilled with all
of it, and wish that I could have changed the outcome in some respects, but at
this time I think this position is the least of the potential evils.

I am suddenly reminded of the Caller-ID debate; perhaps some of the 
disagreements here are similarly based on differing assumptions concerning 
what the default/desirable cases are.  The more I think about it, the more I 
suspect this may be the case.

It is obvious to you that self-authenticating messages are the default,
and that other applications are exceptions.  It may be just as obvious to Ned 
and Jim that the reverse is true.  YOU BOTH HAVE GOOD POINTS.

I think this is probably true. Half empty, vs. half full. Certainly we have
different expectations, and perhaps a different set of user/clients in mind.

However, I don't see how we can reconcile them by doing anything other than 
doing what the current proposal does, which is to provide a mechanism for both
modes of operation and let the use of one or both of them be a policy 
decision.  I also like keeping the modes distinct is users' minds, so that 
they can weight the benefits and costs of each with as little confusion as 
possible.

People are much more likely to grasp the difference between "Certified" and 
"Uncertified" than between "self-certified" and "CA-certified".

As I said to Ned in the previous message, I was hoping that the implementations
would have made that difference clear when examining a self-signed certificate.
I was also in favor of parsimony, for a number of reasons. But I will agree
that while we may not be able to dictate what an implementation does with
respect to warnings, the difference in the syntax is more obvious in the
Certified vs. Uncertifiied case. I have also been concerned about the use of
bare keys and the difficulty that is likely to raise with respect to
certificate revocation, but perhaps that is an issue that users will have to be
led to. There are a lot of AOCE implementations now that don't have CRL support
either, even with certificates.

As I have said all along, I desparately want PEM, and PEM/MIME to succeed. My
only concern has been the extent to which support for bare keys and the absence
of a CRL mechanism might serve to put a nail in the coffin of certificate-based
systems, which some of the authors clearly believe is not (very) viable in any
case. This would have left PGP and other rather half-baked (IMHO) solutions as
the only available options, and thout would have been even a worse outcome.

However, your market insight as to the fact that certificate-based system are
beinning to take off (albeit not necessarily using classic PEM and/or the
reference implementation, which may be broken for other reasons than the
certificate infrastructure), and the fact that the USPS and other players are
beginning to make a serious investment, indicates to  me that the earlier
assessments of PEM's survival were too gloomy. Ironically, the more I became
convinced that certificate=based services are like to become viable and perhaps
eventually the norm, the less I was concerned about the possibility that what
the WG was proposing would hinder that effort. 

In short, I have viewed this entire effort as recognizing a delicate balance of
opposing concerns. If PEM/MIME were to be unreasonably delayed or withdrawn,
the impression that PEM is a non-starter would be more likely to become a
self-fulfilling prophecy. On the other hand, e-mail in general, and MIME in
particular, is in my estimation not likely to become the overwhelming killer
application that will finally put the use of encryption and digital signatures
(especially) by private citizens on the map, and the possibility that approving
PEM/MIME in its current form might end up screwing up the chance to develop a
national public key infrastructure seemed devastating.

The final deciding factor for me has been the work that Warwick and others have
accomplished in producing v3 of X.509. I am now convinced that we can now
progress to a much more reasonable solution to many of the problems that I and
others have been wrestling with two to three years.

Therefore, at this point it becomes of greater value to get something out there
that has a reasonable chance of being adopted that to continue go around in
circles trying to convince someone that my set of assumptions are more
reasonable than someone else's.

I'm violating my own admonishment to read the final version of the spec before
taking any more positions, but I hope and trust that the editorial changes will
clarify these issues rather than make them worse.

I realize that the amount of verbiage spent on this subject over the last month
or so has been very substantial. The silent readers of this list have had lots
to skim over, and the active participants have had lots of typing practice.  I
hope that the effort was worth it for everyone. At least we can rest assured
that the various subjects received a full and complete airing of opposing
views! :-)

Regards,

Bob


--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603 
Voice: 1-617-466-2820


<Prev in Thread] Current Thread [Next in Thread>
  • Recommendation to proceed to Proposed Standard, Jueneman <=