Let me repeat for clarity here: MIME/PEM does nothing to restrict the set of
environments in which PEM can be deployed, only to expand it. Non-MIME
environments are untouched by the proposal.
Technically, I agree with you. MIME-PEM is yet another format for
secure e-mail messages. It happens to be MIME and it happens to use
some sort of public-key mechanism. It could have easily been designed
for PGP which I truly think should have been the authors' first
attempt at integrating security with MIME (it's not too late).
Afterall, there is the preception that PGP is or will be used more
than PEM.
You are certainly in the process of guaranteeing the truth of your
last statement.
MIME-PEM does nothing to solve the inherent difficult problems as seen
by classic-PEM namely, the requirements for the security services, user
interface and transparency, and does little (except for specifying
cert/crl retrieval messages) to provide a key/crl mangement structure
for pk information retrieval.
On the contrary. By leveraging off of MIME the MIME-PEM proposal attacks the
user interface and transparency issues head on, and already wins in ways that
classic PEM never did. This is far from a complete solution, but it is a HUGE
step in the right direction, in my opinion.
As for the management structure issues, as you say MIME-PEM does provide the
one service that we could think of providing. However, I think a far more
important change is the ability to deploy MIME-PEM services without having a
management structure already in place. MIME-PEM lets you get started small and
then build the structure you need. The advantage here is mostly psychological
in nature, but that doesn't change its importance. (I've been doing this sort
of stuff for over 10 years now, long enough to be more than a little cynical
and jaded, but even I felt a strong rush of satisfaction when MIME-PEM services
starting working here with minimal setup time and effort on my part. This
experience was sadly lacking in all the attempts I've made to use classic PEM.)
Given the above, and the way MIME-PEM was introduced:
1) First drafts used "obsolete RFC 1422" (now re-phrased)
What old drafts of the specification said is no longer relevant. The change
has been made. It will be up to the working group to decide in the future
what happens to classic PEM services.
2) Removal of the only Internet reference implementation of
RFC 1422
I'm sorry to have to say it, but this is pathetic. Classic PEM is dead and all
we're missing is the graveside service if the availability or non-availability
of a single implementation is this important.
I am not convinced that the statement "MIME/PEM does nothing to
restrict the set of environments in which PEM can be deployed, only to
expand it." is an accurate portrayal of the reality and a valid
prediction for the future course of this WG. It is, for one, not
clear how (if at all) this WG's scope could/should/would cover two
parallel RFCs.
The only thing that matters at this point is what the documents say. If you
have specific issues with the wording please raise them.
Ned