Date: Mon, 7 Jun 1993 13:24:19 -0500
From: shirey(_at_)mitre(_dot_)org (Robert W. Shirey)
You might have seen it, but some PGP (Pretty Good Privacy, the RSA+IDEA
scheme) users have figured out they are going to soon have a key management
crisis because of the number of keys involved. (Don't know if they
have figured out they have assurance problems because of their lack
of certificates.)
Point of information; PGP *does* have certificates, or at least the
general concept of certificates. What they don't have is a strict
hierarchy of CA's only being allowed to certify keys lower in the naming
hierarchy. (i.e., what unconstrained X.509 certificates provide)
This makes the assurance problem harder for naive users, but for
experienced users, it is hardly impossible. Also, PGP's model of "fully
trusted entities", which function like a PEM root entity, and "partially
trusted entities", wherein n people must signed a name/key binding
before a binding will be listed as trusted by PGP is quite interesting.
It is certainly not suitable in many of the environments where PEM would
be deployed, but there are also many environments where this model works
just fine.
I'm also not sure if it's a key management problem or a key distibution
problem which was discussed, given the messages you forwarded. If it's
a key distribution issue, note that PEM's methodology of including
certificates in PEM messages in the absense of a global X.500 directory
service works just as well for PGP as it would for PEM.
If we want PEM to compete successfully with PGP in the general
marketplace of protocols and implementations, I believe we should
proceed knowing the true strengths and weakness of the "opposition", if
we want to view it as such.
However, it is just as true that what wins in the general marketplace is
not determined by what is technically superior, but what is widely used
first --- example: MS-DOS. For this reason, let me add to John Linn's
note of appreciation/congradulations of the release of several PEM
implementations in the last week.
- Ted