From: Ned Freed <Ned(_dot_)Freed(_at_)innosoft(_dot_)com>
This then means that there will be no less than four S/MIMEs:
(1) The original RSADSI S/MIME.
(2) The one that's coming out as a set of informational RFCs.
(3) The one the WG will standardize.
(4) The one that will result from the PKCS rewrite that RSADSI is supposedly
doing.
Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of
compatibility between all of them -- I wouldn't know about that. But let's
hope
that we don't have quite so many PGPs...
Wow, that would be a lot of S/MIMEs, if they were truly different. But...
(1) and (2) are supposed to describe the identical (not just compatible)
protocol - it's just a matter of writing down S/MIME v2 as Informational
RFCs, perhaps making technical corrections, clarifications, and collecting
dispersed information into a single document. This would be analogous to
publishing an Informational RFC on PGP 2.6.
There is discussion regarding (3) and (4); IETF S/MIME was originally
supposed to be based on the PKCS#7 v2 message syntax, but the Internet
Drafts for IETF S/MIME are now based on PKCS#7 v1.5, with the minimum
changes required to accommodate algorithm flexibility, signed receipts,
and a couple of other flaws. This syntax might have been called PKCS#7
v1.7 (v1.6 included mods to accommodate the SET credit card
protocol), but it is not - the PKCS#7 name will no longer be used - it
is now called the S/MIME Cryptographic Message Syntax (CMS).
The evolution of CMS will be determined entirely by the IETF S/MIME
working group - it may incorporate features from the independently-evolving
PKCS#7 v2 or it may not. But in no case will there be two IETF (Standard)
S/MIMEs; there will be only one, and it will be based on CMS.
To summarize, there will be only two S/MIMEs: v2 described by original
RSA documents and Informational RFCs, and v3 described by whatever
Standard RFCs are produced by the working group. There is the intent
that v3 will *allow* backwards interoperability with v2, but there is
no MUST requirement for implementations to support backwards-compatible
algorithms and message formats.
Sorry to burden the PGP list with this level of detail on the competition,
but accurate information is in everyone's best interest.