Nothing is "wrong" with PGP. However, I don't believe it is as fully
engineered as PEM, not as "complete", nor designed for the long-range
goal of scaling to the size of the Internet and supporting the full
range of Internet applications and users -- academic, government, and
commercial -- in "serious" applications. If PGP was so engineered,
it would have to look like much more like PEM.
What is needed is for someone in the PGP community to produce an
Internet-Draft documenting the PGP design, and explaining why it should
continue to live. That is, what are its non-PEM virtues? (E.g.,
Edward Vielmetti has suggested some reasons.)
Then, assuming enough agree that PGP should live, a way is needed for
PGP and PEM to interoperate. Because I, a "user", refuse to have to
devote resources to the care and feeding of two different email
security systems. Thus, an evolution/convergence plan is
needed.
I may be misinformed, but the following is a my summary view:
(1) We designed and engineered PEM for the long-haul, intending
Internet-wide deployment and use for purposes ranging from personal
mail to bills of lading to filing tax returns. PEM deployment has
been (grieveously) delayed by efforts to establish infrastructure
needed for a system of that scale.
(2) PGP began (apparently) with more modest goals, has or needs not much
infrastructure, has gained a following, but will have trouble scaling.
(3) The systems are so similar in their services THAT IT IS STUPID TO
HAVE TWO OF THEM!
PEM World PGP World
---------- ---------
RFC 1421 No spec, no engineering for
In short, the "protocol", related protocols.
designed to fit with other
protocols in the Internet
suite and, "eventually", X.400.
RFC 1422 Infrastructure not scalable, no spec.
In short, the public key
infrastructure, designed Not ready for X.500 DIT. No DN
to scale to the Internet. concept, transfer syntax.
RFC 1423 IDEA and RSA, but no spec.
The algorithms, because (Selection based on confused info
"the protocol" is algorithm about DES and export laws.)
independent; with specific
specs.
RFC 1424 Not thought out yet; different
paradigm.
Key Certification and May not be necessary in some usage.
Related Services.
Regards, -Rob- Robert W. Shirey SHIREY(_at_)MITRE(_dot_)ORG
tele 703.883.7210, sec 703.883.793, fax 703.883.1397
Principal Scientist, The MITRE Corp., Mail Stop Z202
7525 Colshire Drive, McLean, Virginia 22102-3481 USA