Sure, I'm willing to comment, but I am not sure this thread is pertinant to
this list. This mailing list isn't for discussions about X.509 or PGP,
except as they relate to S/MIME. If the subtext here is "should S/MIME
support PGP?" I understand why it is here, and think that the answer should
be yes.
You are indeed correct that PGP 2.x doesn't have all the function that one
might possibly desire. If it did, then I'd probably have a different job now.
We are actively enhancing the PGP infrastructure, and we are releasing
source code, freeware, and documents describing what we're doing. The first
enhancements we made shipped with V5.0. These include a new format for key
material and signatures, deprecating any algorithm in it that isn't an open
standard (for examples, both RSA and IDEA, which were the only algorithms
available in 2.x), and so on.
Within the next year or so (insert the usual disclaimer that this isn't an
announcement or commitment), you'll see us add in a number of other
features such as:
- support for strict hierarchies within the web of trust (which handle the
same sorts of issues as cross-certification, differences of meaning when
crossing national (or more importantly, corporate) boundaries)
- folding X.509 certs into PGP so that they look a lot like a user id with
a signature
- notations within a signature that serve the same purposes as extensions
do in an X.509 cert
- signature expiration and on-line validity checking, so as to avoid those
nasty CRLs
- message encoding that's compliant with PKCS 7 V2.0
And so on.
In designing our futures, one of our precepts is that we're not religious
about data formats; we save our religious fervor for semantics, trust
models, not doing weak crypto, and so on. I have no particular love for
ASN.1, but I could completely recode PGP into it. Similarly, I could
completely code PGP using SPKI syntax. If you have good reasons for either
of these, I'd love to hear them.
Our goals for the next few versions of PGP are to (1) provide solutions for
our customers so that they get a strong, no-compromises security
infrastructure that interoperates with whatever they have and (2) to create
an open framework for PGP so that other people can make interoperable
applications.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
Senior Security Architect 555 Twin Dolphin Drive
Pretty Good Privacy, Inc. Suite 570
(415) 596-1960 Redwood Shores, CA 94065