The task of picking a winner is best left to the market.
S/MIME can be operated in PGP mode, and I expect to see
this emerge shortly.
Let me add my puzzled voice to Derek's query. What, exactly, does
this mean? I have been participating on the imc-miso-start mailing list,
which is chartered to identify, justify, and resolve the differences
between PGP, S/MIME. and MSP. I have seen _no_ substantial progress
towards integrating S/MIME and PGP.
I have not followed IMC activities.
Lets do some old-style IETF community-spirited work:-
X.509 subject public key is a bit string. So, now arrange so that
authority-issued certificates carry the existing PGP signed key blob
rather than the existing SEQUENCE (n, e). X.509 (nor VeriSign) doesnt
care a hoot so long as the syntax is identified. Include a SPKI
format, similarly. (A minor byte search can locate the fixed
value identiter field preceding this string. This would eliminate
the parsing of the X.509 BER, for those implementations that
cannot decode ASN.1 BER, or are only interested in the PGP/SPKI
portion of the certificate.)
Similary for the EncryptedKey OCTET STRING in PKCS7.RecipientInfo.
Have it carry (redundantly) the PGP encoding of the (complete) per-recipient
token (in base64!). The syntax encoded by the base64
is flagged by the alg id.
Similarly for the PKCS7.SignerInfo EncryptedDigest (OCTET STRING), have
this field carry the pre-existing PGP signature format. Flag the
syntax within the base64 encoding with the digestEncryptionAlgorithm value.
Im confident that the formats of PGP could be encompassed within
S/MIME. The UA message processing, key management, and MIME interaction
can then be assumed, whilst using the deployed based of PGP code
to generate the PGP primitive formats, which are placed into the S/MIME
stream.
It will require a refined PKCS7 profile so that the more advanced
features of PKCS7 are removed to ensure PGP processing mode
equivalence. Based on the algid of the recipient certificate
the originator UA can format the internal S/MIME security mechanism
formats intentionally for a PGP-restricted UA at the receiving side.
On recognising an "S/PGP" message, the minimal S/PGP (only really
does PGP) UA can strip the redundant S/MIME wrappers and reconstract
a PGP 2.5 format message for passing on to the existing deployed
binaries.
Again, this only require searching the binary stream for the fixed bytes
in the BER which identity the PGP mechanism formats. Then
pull out the PGP strings which are formatted as currently in
PGP 2.5 BNF.
We could ask S/MIME next generation products
to perhaps add to the S/MIME spec so that support for the
PGP mechanism formats are required, to promote harmonization of
S/MIME and PGP. We can define the oids to indicate the syntax of the
mechanism blocks.
The general-purpose PKCS7 syntax underlying S/MIME
is extremely flexible in these regards.
This is not a fully worked solution. What do
you think about the basic notion?
Both you and I have PGP source and S/MIME/PKCS7 source available.
Should we try to merge the two formats along these lines
as an experiment?