Last week's UPDATE column on S/MIME just began to scratch the surface of the planning, deployment, and operational problems surrounding widespread use of S/MIME ("Email Security and S/MIME," August 30, 2007). As I mentioned, one of the major stumbling blocks to S/MIME adoption is the need to trust other organizations' certificates if you want to exchange encrypted email with users in those organizations. Another problem is that S/MIME access has traditionally not been very portable; to send signed messages or receive encrypted ones, you need to have your certificate with you. That requirement has posed a problem for users who want to be able to seamlessly send and read mail from more than one device.
In the desktop world, this problem was solved by Microsoft's decision some years ago to support the Public-Key Cryptography Standards (PKCS) #12 standard for secure software storage of private keys. A PKCS #12–format file, also known as a personal information exchange (PFX) file, can be used to copy a certificate and its associated keys to a small file that can then be imported to another device. PFX support makes it possible for you to receive a certificate on your desktop machine, then export it and use the copy on another machine. However, the Certificate Authority (CA) can mark a certificate as nonexportable, which eliminates this option. This solution also fails to address two other common cases: OWA users and Windows Mobile users. Exchange Server 2007 RTM didn't support S/MIME for either of these platforms, but SP1 returns that support.
At first glance, these uses may seem very different: OWA users might not have a place to store a certificate, while Windows Mobile users will. However, there are a number of similarities in the way S/MIME works on these two platforms. First, both platforms still require a local copy of the user's certificate in order to sign mail or read encrypted messages. For OWA, this means you'll need a smart card and the appropriate reader, which limits S/MIME's utility somewhat. However, it would be foolhardy to manually import your certificate to every machine on which you use OWA, so the smart card is a reasonable tradeoff. Windows Mobile devices can use a locally installed certificate, or they can use a smart card with the aid of an external reader. Windows Mobile 6.0 includes some significant enhancements in this regard, including the ability to request a certificate directly from the device and a tool for importing PFX files directly.
You might wonder what Exchange 2007 SP1 adds to enable S/MIME support for OWA and Windows Mobile. The answer lies in the difference between S/MIME cryptographic operations. Signing or decrypting messages doesn't necessarily require anything other than your local certificate (although all S/MIME clients should check the validity of the sender's certificate chain when you open an encrypted message). But verifying a signature or encrypting a message both require access to another user's certificates, which implies a requirement for access to the certificate chains and certificate revocation list (CRL). For OWA and Windows Mobile clients, Exchange handles signature verification on the server, along with CRL checking, and it also provides a means to fetch user certificates from the Global Address List when needed. There's also the OWA S/MIME control itself, which is required to let OWA running in Microsoft Internet Explorer interact with the smart card.
Even with these changes, S/MIME isn't for everyone. Pretty good privacy (PGP) is a popular alternative, and some organizations fall back on file encryption tools that process attachments without touching the original message. However, the SP1 improvements not only restore the functionality we lost in Exchange 2007 RTM, but they add significant new capabilities as well.
End of Article
Register
