Internet Data Object Security

Prepared for:

The G5 Messaging Forum

by:

D. Crocker
Brandenburg Consulting

G. Klyne
5th Generation Messaging Ltd.

 

March 12, 1998

Contents

Summary

Introduction

    Internet Mail
    Security Services
    Key Management
    Selecting Mechanisms
    Channel versus Object Security

Historical Candidates

    PEM
    MOSS
    Security Multiparts
    MSP
    PGP
    S/MIME
    Recent developments

Technical Summary

Strengths and weaknesses

    Configuration
    Experience
    Certificate and Key Management

Key supporters

Intellectual property rights (IPR)

Assessment

    Immediate vs. long-term interoperability

Appendix

    Email Model
    Mechanisms for Achieving Security
    References
    Tracking the continuing debate

Summary

Commercial use of Internet mail requires basic assurances of message authenticity and privacy, as well as transmission reliability. To date such security services have not been available in products or have been poorly deployed and difficult to use. This is, finally, changing. Unfortunately the change is resulting in an excess of riches, with two different technologies competing for dominance. Pretty Good Privacy (PGP) is from a grass root effort in the early 90s and has significant deployment and use. However Qualcomm's Eudora is the only major product that supports it and it has never achieved mainstream acceptance by the commercial community. Secure MIME (S/MIME) was developed recently, by an industry consortium, and is now appearing in a number of major products, notably from Netscape and Microsoft.

Both technologies provide competent security for authentication of the originator and for data privacy. Neither provides a complete solution for large-scale management of public keys. PGP is theoretically easier to use for small-scale environments, although current operation tends to make its use almost identical with the effort needed to operate S/MIME. Further, enhancement efforts for S/MIME will shortly support signed receipt, voluntary security labels and authenticated message trace (audit) recording.

Over the last two years there has been a swinging pendulum of likely dominance between the two technologies. As products are finally being deployed and used and as formal standards efforts are proceeding, the final winner seems clear. PGP has the edge for current use, due to its installed base and real user experience. However S/MIME has broader support from major vendors, is quickly getting more extensive deployment, and now appears to be the inevitable winner in the market.

Introduction

This report discusses the current candidates for Internet data object security, briefly reviewing the history leading up to the current status, the nature of the differences among the choices and an assessment of likely outcome(s). This report solely represents the opinions of its authors. The topic of discussion is both controversial and volatile. Which of the two contenders will win in the marketplace is not yet entirely certain. Hence, the opinions expressed here represent the authors' best effort at assessing a situation that sometimes seems built on quicksand.

The effort to develop security mechanisms for Internet Mail has had its scope broadened, to be security for standard Internet "objects". This is directly due to the success of the data labeling and structuring standard, called MIME, which is used both for Internet mail and for the World Wide Web.

The remainder of the introduction briefly reviews the technical issues for achieving security with Internet mail. Any candidate technology must provide the indicated services and attend to the indicated issues.

Internet Mail

Internet mail follows the classic model involving user agents (UA) and mail transfer agents (MTA). A UA performs actions on behalf of an individual user and an MTA performs mail relaying and mail delivery. A depiction of this model is contained in the Appendix. End-to-end services are considered to be interactions between user agents. Single-hop services can be between a UA and an MTA or between two MTAs.

Security Services

The term security is multi-faceted. It encompasses a range of different services. For commercial uses of Internet mail, the services of primary concern are:

Integrity Detects modification of the data. Simple data integrity mechanisms do not seek to detect or protect against malicious modification; this protection is typically achieved by combining the integrity mechanism with an authentication mechanism. Using a checksum or CRC algorithm, or the like, to compute a short "hash" of the data produces data integrity. The hash is carried along with the data. A new hash is computed by the recipient and compared to the version the originator sent. The nature of the algorithm that is used will depend upon the types of changes to the data that are anticipated. For example, simple communications channel will place less stringent demands upon the hash function than changes due to malicious intent. The latter requires making it difficult for an adversary to construct a different message that yields the same hash value. The hash is also called the message digest (MD) or the message integrity check (MIC).
Identification Labels originators and recipients, that is, entities associated with the data. Verification of an identifier is a separate step, called authentication.
Authentication Associates an identifier with data, in a manner that can be verified by an independent party. This capability is often called digital signature, but that term can also be a synonym for just the message digest; hence the term digital signature will not be used in this report. With public key technology, the originator uses their private key to encrypt the message digest. Then, anyone can use the originator’s public key to decrypt and view the digest. If the result agrees with the recipient’s own calculation of the digest, it is presumed that the originator signed the data. Otherwise, either the message is not really from that originator or the message was modified in transit. Hence, authentication serves to verify both the origin and the integrity of the message.
Privacy Also called confidentiality or encryption. Re-codes message data so that an unauthorized party cannot read it. Encryption of the data is usually done with a symmetric (single-key) algorithm, because it is computationally faster than public key technology. Hence, a single-key is used to encrypt a single message; this is called the session key. The session key is then separately encrypted using the public key of the recipient. Only the recipient will have the private key needed to decrypt the session key, which in turn is needed to decrypt the data.
Non-Repudiation Certifies to an independent third party that the message was sent or received by the purported originator or designated recipient. At its most stringent, this proof applies to a formal third party, such as a court of law. A less stringent form of this function is often called signed receipt, and is primarily for the purpose of satisfying the originator that the designated recipient did receive the message. Signed receipts are technically much easier to achieve than formal non-repudiation.

Work on MIME security has focused on these services only. It has ignored other security issues, such as denial of service attacks, traffic analysis, use of covert channels, and the myriad of concerns appropriate to military and national security, but rarely a problem for business.

Key Management

The technical community has produced a rich array of choices for basic security services. There is little concern about the adequacy of the algorithms. Most are mature and well understood. This is in marked contrast with the operations issues created by large-scale use of security, especially among uncoordinated, or casual, correspondents, such as independent participants of the Internet. This basic problem entails management of keys. It becomes quite a challenge when there are many participants, each with at least one published key.

The above description of security services referred to originators using the public key of recipients and recipients using the public keys of originators. How do they obtain the keys? Once they obtain the keys, how do they gain assurance that the keys are actually associated with their purported owners? Essentially no operations experience exists for key management in very large, diffuse environments like the Internet.

The construct used for resolving the question of large-scale key management is certificates. A certificate associates an identifier with a key and verifies their relationship. The creator of a certificate is a certification authority (CA). That is, a CA is a trusted entity that validates keys. The reader may notice that this simply moves the problem of trusting keys to one of trusting CAs. The usual way a CA is assigned trust by users is by specific and conscious user decisions. An elaboration to permit larger-scale use of CA's is to have a hierarchy of trusted CAs.

Selecting Mechanisms

Partially due to differences in computational cost and questions of effectiveness, but primarily due to difficulties with restrictions imposed by national authorities, a system designed to provide security services needs to be able to employ different certification schemes, different algorithms and different key sizes, for different situations. This means that a security standard must include a way for selecting among the alternatives. Each user may support different combinations of alternatives. This creates a need for specifying each recipient's capabilities.

Until recently, essentially all commercial use of public key technology in the US has been through RSA Data Security, Inc. (RSADSI, www.rsa.com) recently purchased by Security Dynamics (www.securitydynamics.com). Because RSA has a patent only in the US, the world market has not had a problem with using RSA’s technology; on the other hand the US has been a primary source for security software. With the recent expiration of an associated and earlier patent that is not under the control of RSADSI, interest in the use of key exchange based on Diffie-Hellman (DH) and the related ElGamal public key algorithms has become intense.

Channel versus Object Security

This report discusses security services for MIME data objects. That is, security is associated with distinct chunks of data. As the data move through each leg of the communication system, associated security information moves with it. Hence the security mechanism is entirely independent of the details of the communications channels. This approach is sometimes referred to as using a security wrapper.

A different approach to security is to associate security with the communication channel, independent of the characteristics of the data moving over the channel. Modems that encrypt data use this approach. So, too, does the SSL capability produced by Netscape (www.netscape.com) for interactions over the World Wide Web. This is being standardized as Transport Layer Security (TLS). Email use of channel security is considered most appropriate for privacy and authentication between clients/server pairs, specifically UA/MTA interactions and MTA/MTA relaying, although interest in the latter is primarily for authentication to restrict use from spammers. This permits a server to assume some of the end-to-end duties of the client, even including the work of adding and removing security wrappers to email data objects.

Historical Candidates

Development of security technology for Internet Mail has been the subject of several official efforts since the late 1980’s. The first project began in the Internet research community and entered the Internet Engineering Task Force (IETF) standards process as Privacy Enhanced Mail (PEM). Problems with that work eventually led to a retrenchment, calling it MIME Object Security Services (MOSS). Frustrations with the delays in PEM motivated a private effort which produced Pretty Good Privacy (PGP) in the early 90's, headed by Phil Zimmerman, now CTO of PGP, Inc. (www.pgp.com) which was recently purchased by Network Associates (www.nai.com). Further industry frustrations led to an initiative by RSADSI to produce Secure MIME (S/MIME) starting in 1995. An entirely separate effort came from the US Defense Message System (DMS) project, producing Message Security Protocol (MSP).

PEM

The PEM work is notably only for its residual effect on MSP and S/MIME. As a standards effort, it is dead. There is no meaningful development or support of this technology. The work intentionally did not integrate with the nascent MIME effort, therefore requiring its own mechanisms for structuring data and for protecting it against the vagaries of transport services. Further, PEM required a global, formal, hierarchical CA service. No such CA service was fielded; this was one of PEM’s several critical deficiencies, along with inadequate flexibility in choice of algorithms and failure to integrate with MIME. A variant of PEM, called RIPEM, gained a small base of use but that has disappeared. PEM currently has no installed base and no products available or forthcoming.

MOSS

In response to the various concerns about PEM, a renewed IETF standards effort was undertaken. The result suffered from too much perceived complexity, some replication of MIME’s facility for partitioning and labeling chunks of data, and a lack of community support. MOSS is officially an Internet Standard. However it, too, has no installed base and no products available or forthcoming.

Security Multiparts

A portion of the work done during the MOSS project is still alive and was never specific to MOSS. This is the development of two MIME Multipart mechanisms. Multipart/Signed is now the default choice for active Internet mail security technologies that provide data authentication. It separates the authentication information from the clear-text message content. The considerable benefit of this separation is to permit normal access to the content without having to process the security information. Hence, regular message readers still work and IMAP can still get at the message sub-components, without having to know anything about the details of the security technology.

Multipart/Encrypted was defined for data privacy and also separates data from control information. It has not been as fortunate as Multipart/Signed. Given that the privacy function must distort (encrypt) data and thereby make it inaccessible unless decrypted, there is little benefit in separating out the content from the control information. One circumstance that would make Multipart/Encrypted valuable would be if competing technologies used the same content encryption and encoding algorithms, differing only in the control sections. As of the time of this report, there are no signs that such cooperation will happen among the two, primary contenders, in spite of their both using the same set of default encryption algorithms.

MSP

The Defense Message System (DMS) effort was based on the ITU's X.400 mail standard, so that Message Security Protocol (MSP) had no direct relationship with Internet Mail, although the MSP security techniques are essentially modeled after PEM. However some of the contractors for that project decided to apply the functional requirements for DMS to Internet mail and are developing an equivalent set of functionality, such as for signed receipt. The recent, explosive success of the Internet and of Internet mail is causing the DMS to re-target its technical goals to use Internet mail. The MSP work is focusing on specification of functions to be added to candidate Internet mail security technologies, to satisfy DMS needs. It is being done in a way that will be of direct and considerable benefit to the commercial sector.

PGP

The Pretty Good Privacy effort is an excellent example of the benefits that accrue by limiting choices and minimizing mechanism. The original PGP had one algorithm for encryption and its "CA" structure was flat and simple. The way a recipient knows to trust a key is that they obtain it directly from the owner or they get it from an intermediary directly trusted by both parties. This is called a web of trust model. It benefits from having no prerequisite for establishing a formal, complex CA structure. The deficiency is that it does not scale adequately for formal, global use. Global and formal systems appear to need multiple levels of certification, or else everyone would need to be certified by a single authority. In principle the PGP web of trust model can be extended to permit this hierarchy, but there is not yet an operational example of such an extension.

The original PGP technology is monolithic, having its own data structuring conventions, compression and transport armoring mechanisms. Recently a method was developed for carrying an entire PGP object inside MIME, but did not identify the pieces of PGP with MIME structuring and labeling.

PGP now has four distinct versions:

The OpenPGP effort is focused on retaining compatibility with deployed PGP and therefore is unlikely to fully integrate with Internet Mail to the extent otherwise possible. The working group is not proceeding very aggressively and generally does not seem overly concerned about competitive pressures. Stranger still is that it is risking further marginalization by choosing unique algorithms, such as its own variant of Triple-DES. This ensures complete non-interoperability with S/MIME, for example.

S/MIME

Having almost complete control over the use of public key technology in the United States has given RSADSI special access to the broad range of vendors who might implement security technology. It also has provided a base for RSA’s sale of software packages, which implement a number of derivative capabilities. S/MIME was started as a private multi-vendor consortium, leveraging that existing set of RSADSI software into a package for email security. The effort resulted in a specification for S/MIME version 2.0, which is now being fielded.

In spite of assurances that the work would be submitted to the Internet standards process, it was kept outside of the IETF, and this became quite problematic by the summer of 1997, as well as quite visible in the trade press. From the public exchanges about standardization came changes in the management of the S/MIME effort, finally resulting in chartering of an IETF standards working group. It will develop S/MIME version 3.0. Leadership for the effort has moved from primarily RSADSI over to a set of product vendors and major users of the technology.

Because it is based on earlier work by RSADSI, S/MIME carries some technical baggage, in particular involving the use of ASN.1 and mechanisms for selecting algorithms. ASN.1 is relatively complicated and it creates a binary object. MIME supports binary, but such data are not handled as efficiently as text-oriented data, by the vast majority of Internet mail transport services. Even though many messages are fully textual, using S/MIME to sign them forces the data to be treated as binary. As with PGP, this makes integration of S/MIME into Internet Mail more complicated than one would like.

Recent developments

PGP has moved to primary use of non-RSA technologies, in time for expiration of the Diffie-Hellman patent. Even with the specification (and use) of PGP/MIME, the approach to PGP packaging continues to emphasize independence, so that the "armor" around the control information is retained inside the MIME body-part. The nascent OpenPGP standards effort appears likely to continue this. Although not part of the public debate, PGP implements data compression, to counteract the object inflation required when adding the radix64 armoring. S/MIME has no equivalent feature. Encryption introduces randomness to data, thereby defeating the effectiveness of compression; hence compression must be performed prior to encryption.

S/MIME was pointedly designed to use specifications and software that had already been developed by RSADSI. General concerns about licensing and specific concerns about RSADSI’s trade secret status of the RC2 algorithm motivated addition of support for alternatives. The IETF-chartered S/MIME 3.0 effort is likely to support a number of new algorithms, in particular using unencumbered algorithms as the default, but without making any basic changes to "packaging" style. RSADSI has recently published RC2, so that it is no longer secret.

Technical Summary

PEM, MOSS and MSP are significant primarily for historical reference. They have no meaningful commercial support. Only PGP and S/MIME are viable candidates for global email security. PGP's notable deployed support are Qualcomm's Eudora and Microsoft's Outlook Express. It is also supported in, or being added to, a few email packages that are less well known. S/MIME's primary support includes recent deployment in Netscape Communicator and Microsoft's Outlook. Worldtalk offers an S/MIME plug-in for Eudora.

The table listing their component technologies uses row headings with these meanings:

Signing,
Encrypting		 Packaging sections of data and control information into Internet Mail and distinguishing between the sections
Records Separating internal information "records" and fields
Transport Protection Protecting data against vagaries of transport services--especially email transport--by adding a layer of data encoding, for example, so that trailing white spaces are not eliminated
Selection Mechanism for specifying choices among algorithms, etc.
Certificate Associating identifiers with keys and validating the association
Session Public key mechanism for exchanging random session keys between correspondents
Digest Algorithm(s) for performing data integrity hash calculation
Signed Algorithm(s) for encrypting content digest, to achieve data authentication
Encrypt Algorithm(s) supported for encrypting content data to achieve privacy

Algorithms and mechanisms cited in the table are:

ASN.1 Data encoding as records in a binary, hierarchical structure, with type and length headers for each field.
CAST5 New data encryption algorithm developed in Canada, limited by a patent claim
CMS Cryptographic Message Syntax, an open specification derived from RSADSI's PKCS#7
DES Data Encryption Standard promoted by NIST; Now deemed easy to compromise; Triple-DES is a much stronger enhancement
Diffie-Hellman The first public-key algorithm, with utility limited to exchange of session keys.
DSA Digital Signature Algorithm promoted by the U.S. National Institutes of Standards and Technology (NIST)
ElGamal Variant of Diffie-Hellman which can be used for signatures and encryption
IDEA International Data Encryption Algorithm, used in the original version of PGP
MD5 Popular message digest algorithm which produces a 128-bit hash
MIME Multipart/Signed, Multipart/Encrypted, MIME Content-Transfer-Encoding, etc., as appropriate
PKCS#7 RSADSI's ASN.1-based common cryptographic syntax for "records" or sets of fields, such as for signed data, encrypted data, certificates and certificate revocation lists
PKIX Open public key certification mechanism based on the International Telecommunication Union’s (ITU) X.509v3 being developed by the IETF
RSA Public key algorithm that can be used both for encryption and digital signatures
SHA-1 Secure hash algorithm promoted for message digest use by NIST

In the following table, bold entries indicate the mandatory default choice. The term "Special" refers to use of techniques developed specifically for the cited work, rather than being developed independently and/or for more general use. Note that OpenPGP and S/MIME v3 are still under development and, therefore, subject to change.

 

PGP 2.6

(Classic)

PGP/ MIME

(IETF)

PGP 5.0

OpenPGP

(IETF)

S/MIME v2

S/MIME v3

(IETF)

Packaging

Signing

Special

(Text in Body)

MIME

Special, MIME

MIME

MIME, Special

MIME, CMS

Encrypting

 

Special

 

PKCS#7

CMS

Records

 

Special Binary

 

PKCS#7

CMS

Transport Protection

Special

(ASCII Armor)

MIME and Special

Spec

ial

MIME, Special

MIME

Selection

 

Special Binary

 

PKCS#7

CMS

Algorithms

Certificate

  Special (Web of trust)  

X.50
(PK

9 v3

IX?)

Session

RSA

ElGamal, RSA

ElGamal

RSA

Diffie-Hellman (X9.42), RSA

Digest

MD5

SHA-1, MD

5

SHA-1,

MD-5

Signed

RSA

DSA,

RSA

RSA

DSA, RSA

Encrypt

IDEA

CAST5, IDEA, TripleDES

TripleDES (EDE), IDEA, CAST5

RC2-40, TripleDES

TripleDES (CBC), RC2-40, DES

Technical Summary of MIME-Based Security Mechanisms

Strengths and weaknesses

Both PGP and S/MIME provide security sufficient for commercial purposes. The PGP framework is designed to work alone, without MIME. To some extent S/MIME was also designed this way, and neither group has fully abandoned that style. Some degree of development cycle "phase" differences can be seen from the timing of work on each. Whichever is more recent tends to show somewhat more features, clarity, integration or the like. The other then adds them. Hence, the real areas of debate are matters of configuration, as well as operational experience with deployment, use and support. The primary deciding factor is vendor support. The technical point that has engendered religious debate is key management. For most users there is no longer a meaningful difference since, to be useful in normal service, both now require a key server.

Configuration

The only technical difference between PGP and S/MIME, worthy of serious debate, is the configuration choice of default key sizes. Due to the difficulties of government restrictions, use of sufficiently strong key lengths is problematic. Hence, the groups developing these specifications have had to decide whether to make a choice for weak but exportable sizes, or to stand firm for strong cryptography. PGP has, so far, remained firm with their choice of only strong encryption. S/MIME v2.0 has specified a weak default, 40-bit key for encryption. This was recently demonstrated to be easy to break quickly with common, off-the-shelf desktop hardware and straightforward software. The IETF has established a policy that it will only standardize on the use of strong encryption and any work produced out of the IETF is expected to follow that policy.

Experience

PGP Classic has several years of significant, global operational experience and has a substantial installed base. Conversion to the newer PGP 5.0 is greatly facilitated by freely available plug-ins, especially for Eudora, which are easy to use. MIT has been offering PGP key storage and recently PGP, Inc. began to offer service. Although small in terms of potentially global operations, these are providing a useful base of key management experience among unrelated users.

S/MIME v2.0 products have only been being released for less than a year. Netscape’s inclusion of S/MIME in Communicator 4 and Microsoft's inclusion of it in Outlook have already given it a very large, but if untested, market. However certificate management experience for S/MIME is almost non-existent.

Still, the basic experience of using S/MIME and PGP is quite similar, at this point. The newest set of software products supporting S/MIME and PGP are far easier to use than earlier packages, primarily for PGP. However they are still quite awkward to install, less than natural to use, and tending to show some interoperability problems among implementations by different vendors. Such problems should be viewed as a natural part of the product learning curve and will be resolved as end-user experience is gained (and fed back to product developers.)

Certificate and Key Management

Both PGP and S/MIME are problematic with respect to very large-scale certificate management. Simply put, neither has done it. PGP’s model can support monolithic certificate authorities, which will probably scale to some millions of entries, and the MIT and PGP, Inc. key servers offer a good demonstration of basic service. However the kinds of formal assertions needed for some uses and the need for scaling to literally every person and organization on the planet require a more elaborate certification authority hierarchy. PGP no doubt could develop this, but it hasn’t. That makes it currently problematic for some uses, although well established for many daily uses.

S/MIME can claim the higher moral ground, since its certificate authority scheme is — theoretically — designed to scale well. Unfortunately it has no real operational history, so that it should be viewed as filled with promise, not proof. Further it is not clear how well it will work for the kind of casual, everyday use in which PGP has demonstrated competence. In reality, the current S/MIME certificate use looks remarkably similar to that of PGP. That is, individuals exchange keys or single-server authorities provide stand-alone certification.

SPKI is an IETF effort to produce a simplified public key certification infrastructure. It is not clear whether it will have any substantial impact in this arena. At the time of this writing, the working group appears to be stalled. PKIX is the major focus of current IETF standards work, intending to provide an integrated certification service for all Internet technologies. The work has proceeded very slowly; the work is complex. It is unclear when users will see direct benefits from this effort. As a consequence the S/MIME documents are choosing to specify no certificate management system, instead simply asserting that users are expected to have certificates available.

Key supporters

PGP’s primary support is from PGP, Inc. and Qualcomm (Eudora). S/MIME’s primary support is from RSADSI and a number of vendors, notably Netscape and Microsoft. Worldtalk also supports S/MIME, including a plug-in module for Eudora. At this point, it is not a question of technical preferences by these vendors but, rather, of protecting their investment. The bottom line is that users of Eudora and Outlook can get a PGP plug-in. Users of Eudora can get an S/MIME plug in. For Outlook and Communicator S/MIME support is built-in, thereby skipping the end-user effort to install a plug-in module.

Intellectual property rights (IPR)

Diffie-Hellman Patent is now expired. A derivative, ElGamal, also is unencumbered.
DSA Has some uncertainty, due to claims that it touches the "Schnorr" patent, however there is little support for this concern and it is generally being treated as unencumbered.
IDEA Patented, but this is no longer a serious factor, since PGP has moved away from using IDEA.
MD5 Unencumbered.
RC2 No longer a trade secret by RSADSI. However they continue to retain trademark on the name.
RSA Patented only in the United States. The patent expires on September 20, 2000 and is held by Public Key Partners (PKP), of which RSADSI is a partner.
SHA-1 Unencumbered.

Hence, the deployment of S/MIME v2.0 remains significantly encumbered by the RSA patent. S/MIME v3.0 defaults to use of Diffie-Hellman and, so, will not be burdened.

PGP 5.0 is not encumbered.

Assessment

Beyond the usual disclaimer about difficulties in predicting the future, MIME and Internet mail security comprises sufficiently peculiar histories and tendencies so as to make commodities trading a comparatively sedate profession. Nonetheless there is, finally, some sign of the likely outcome, although this is but the latest of three or four such apparently definitive milestones, which then get reversed. On the other hand, the current indication is based on shipping product and style of use, which does tend to create meaningful momentum, especially since it is from Netscape and Microsoft.

Both S/MIME and PGP have legitimate IETF standards efforts underway, although the PGP effort is progressing (much) more slowly. The S/MIME effort is focused and near-term.

It is likely that the vendors’ desire to protect their S/MIME investment will determine the outcome. RSADSI’s control of the specification process was problematic but recent changes have resulted in true product vendor (and community) control, with RSADSI being merely one among equals. It seems likely that the current S/MIME v2.0 will be issued as an Informational RFC. That is, it will have no standards status. S/MIME v3.0 will have relatively minor upgrades to the v2.0 structure, but will have the major upgrade of using unencumbered mandatory default algorithms. This will gain standards status.

Further the PGP community retains its interest in traveling an independent path, including limiting the degree of MIME integration, in spite of using Multipart Security for authentication and encryption. The only vendor of note with strong support for PGP is Qualcomm, and a member of the Qualcomm Eudora team has also been a major contributor to the S/MIME effort. While Eudora is the dominant Internet mail user agent, the number of seats associated with Netscape and Microsoft mail products is changing the equation very quickly. Because the newest version of S/MIME will use non-RSA technology as its default, the entry barrier for smaller vendors is greatly reduced, since negotiating a license with RSADSI has often been characterized as problematic.

The reality of current use for both technologies is that users need access to one or more CA servers (key servers). The primary ones for PGP are free to use. The primary one referenced by the Netscape and Microsoft software charges an annual fee. Others are available, but users need to know how to access them.

Immediate vs. long-term interoperability

The nature of the adoption process for the services discussed here should be treated as an "infrastructure" change, which means that it is likely to be at least 2-3 years before dominance by S/MIME or PGP is fully clear, and five years before use is fully common. On the other hand the fact that Microsoft and Netscape have marched down the same road with built-in S/MIME support suggests that the question of final outcome could be resolved in as little as a year. Many would, of course, argue that it is already resolved.

Of course the ultimate question is "what should be done by those developing Internet mail-based security today?" The continuing uncertainty between S/MIME and PGP suggests that an implementation should avoid painting itself into a corner by assuming a single winner. This means that a flexible, extensible software framework is vital. The flexibility can be achieved by carefully modularizing functionality into the different categories used for the Technical Summary chart, shown earlier. This might be more general than strictly necessary but the uncertain future is more than a simple binary choice. Both PGP and S/MIME are being revised and each provides mechanisms for selecting among a variety of sub-choices. In effect an implementation should assume that it must support an arbitrary number of different security algorithms and multiple packaging schemes.

Developers faced with choosing a single standard should ask whether very near-term, general interoperability with deployed software from other vendors is desired or whether long-term interoperability is required.

For those needing instant interoperability with the general email community, PGP is the choice. For those needing long-term interoperability, S/MIME is the choice.

Appendix

Email Model

Mechanisms for Achieving Security

 

 

References

Cryptographic Message Syntax,

Enhanced Security Services for S/MIME,

Tracking the continuing debate

The lists beginning "ietf-" are intended to produce Internet standards. The other lists pertain more to development and vendor issues.

In order to monitor Internet standards and technical issues, a good starting place is the official mailing list for IETF announcements. This is a one-way list and only contains occasional postings for IETF management: