The two basic features of this type of security are privacy (only the intended recipient can read the message) and authentication (the recipient can be assured of the identity of the sender). The technical capabilities for these functions has been known for many years, but they have only been applied to Internet mail recently.
There are currently two actively proposed methods for providing these security services: S/MIME and PGP (both in its early incarnation as PGP/MIME, and as the new OpenPGP standard). Other protocols have been proposed in the past (most notably PEM and MOSS), but they did not garner much interest in the market. However, many major Internet mail vendors have begun to ship products using S/MIME, PGP/MIME, and OpenPGP.
Although they offer similar services to users, the two protocols have very different formats. Further, and more important to corporate users, they have different formats for their certificates. This means that not only can users of one protocol not communicate with the users of the other, they also cannot share authentication certificates. The difference between the two protocols is similar to the differences between GIF and JPEG files: they both do basically the same thing for end users, but thir formats are very different.
S/MIME was originally developed by RSA Data Security, Inc. It is based on the PKCS #7 data format for the messages, and the X.509v3 format for certificates. PKCS #7, in turn, is based on the ASN.1 DER format for data.
PGP/MIME is based on PGP, which was developed by many individuals, some of whom have now joined together as PGP, Inc. The message and certificate formats were created from scratch, and use simple binary encoding. OpenPGP is also based on PGP.
S/MIME, PGP/MIME, and OpenPGP use MIME to structure their messages. They rely on the multipart/signed MIME type that is described in RFC 1847 for moving signed messages over the Internet. A single mail client could conceivably accept and send both formats.
All of these RFCs are informational RFCs. It is important to note that S/MIME v2 is not an IETF standard. S/MIME v2 requires the use of RSA key exchange, which was previously encumbered by U.S. patents held by RSA Data Security, Inc.; further, S/MIME v2 requires the use of weak cryptography (40-bit keys). Both of these issues have prevented the protocol from being accepted as an IETF standard as well.
The current work on S/MIME is being done in the IETF's S/MIME Working Group. S/MIME v3 was made a standard in July, 1999. The charter for the S/MIME WG describes the current work being done. The S/MIME WG has a web page hosted by IMC.
The S/MIME v3 standard consists of five parts:
An additional protocol, Enhanced Security Services for S/MIME (RFC 2634), is a set of extensions to S/MIME to allow signed receipts, security labels, and secure mailing lists. The first two of these extensions will work with either S/MIME v2 or S/MIME v3; secure mailing lists will only work with S/MIME v3.
A freeware S/MIME v3 toolkit is now available in pre-release form. See the toolkit home page for more information.
The S/MIME certificate structure is based on work being done in the IETF's PKIX Working Group. S/MIME developers should probably be familiar with the work being done in that Working Group.
The current work on PGP/MIME is being done in the IETF's OpenPGP Working Group. The charter for the OpenPGP WG states clearly that the purpose of the group is to create protocols based on PGP that can become IETF standards. The OpenPGP protocol, which is on the IETF standards track, is described in OpenPGP Message Format, RFC 2440, which is being revised by draft-ietf-openpgp-rfc2440bis. The MIME wrapping for OpenPGP is described in MIME Security with Pretty Good Privacy, RFC 3156. The OpenPGP WG has a web page hosted by IMC.
|Mandatory features||S/MIME v3||OpenPGP|
|Message format||Binary, based on CMS||Binary, based on previous PGP|
|Certificate format||Binary, based on X.509v3||Binary, based on previous PGP|
|Symmetric encryption algorithm||TripleDES (DES EDE3 CBC)||TripleDES (DES EDE3 Eccentric CFB)|
|Signature algorithm||Diffie-Hellman (X9.42) with DSS or RSA||ElGamal with DSS|
|MIME encapsulation of signed data||Choice of multipart/signed or CMS format||multipart/signed with ASCII armor|
|MIME encapsulation of encrypted data||application/pkcs7-mime||multipart/encrypted|