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.
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.
Given the above, and the way MIME-PEM was introduced:
1) First drafts used "obsolete RFC 1422" (now re-phrased)
2) Removal of the only Internet reference implementation of
RFC 1422
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.
_______________________________________________________________________
Alireza Bahreman E-Mail:
bahreman(_at_)bellcore(_dot_)com
Bellcore, Room RRC-1K221 Phone : +1 908 699 7398
444 Hoes Lane, Piscataway, NJ 08854 Fax : +1 908 336 2943