Although security policy is a corporate concern, e-mail itself is still viewed as a personal technology--with much of the standards d evelopment focusing on individual concerns like personal privacy. In this context, centralized control has a negative Big Brother connotation that appalls privacy advocates. Yet in the corporate environment, centralized control of encryption keys--not signing keys--is vital to maintaining ownership of the organization's assets. Many corporate messaging policies specify that it is the organization--not the individual--that "owns" e-mail content.

The major proprietary collaborative computing platforms--Lotus Development Corp.'s Notes, Novell's GroupWise and Microsoft Corp.'s Exchange--provide advanced security management, though only within the confines of their own borders. Encryption in these platforms is common, both in the message store and as messages move between post offices.

Encryption services are not normally in place for Post Office Protocol (POP)/Internet Mail Access Protocol (IMAP)-based e-mail products or over SMTP links between proprietary and foreign systems. However, enhanced security c an be implemented at the gateway level, as it is in Allegro Group's Encryption Gateway for Novell GroupWise (a PGP-based solution) or in Worldtalk's WorldSecure Server (an S/MIME solution), for example.

Back-end products like these assume that the server can act on behalf of (and assure the identity of) the end client being protected. This is too great a leap for many of us. The approach places great trust in the administrator, does little or no client authentication, and provides security that may be too "coarse" to be considered a complete solution for most enterprises.

PGP Versus S/MIME Authentication and encryption are more appropriately handled by the e-mail client using a standard approach supported by a range of vendors. Plug-ins are emerging for many POP/IMAP- and MAPI-based e-mail clients, enabling "piecemeal" deployments without ripping up the entire messaging infrastructure. Of the two most widely deployed approaches--PGP and Secure Multipurpose Internet Mail Extensions (S/MIME)--the latter is more appropriate for the enterprise because of its comparative maturity, support for centralized key management via X.509 certificate servers and widespread industry support. But don't write off PGP just yet. It has a large installed base, has interest from the Internet Engineering Task Force (IETF), and has introduced enterprise management capabilities. The battle has only just begun.

As of press time, the IETF had officially rejected S/MIME, though very recent developments indicate that it may be reconsidered. Despite this, S/MIME products are rapidly being introduced. Most of the relevant messaging vendors have delivered products or pledged eminent support for it. S/MIME contains elements that are proprietary to RSA Data Security, and this is the IETF's principal objection to it, yet most vendors are licensees of RSA. Vendors like Lotus and Microsoft are replacing their proprietary key management systems with more open X.509 certificate -based services, on which both S/MIME and Web security a re built.

The PGP alternatives also are gathering favor with a few vendors and the IETF, yet PGP's focus on security administration by the individual both wastes effort and robs the corporation of the information that it rightfully owns.