RMS vs. S/MIME: When to Use Each One

Before I get into this week's extended discussion on Active Directory Rights Management Services (AD RMS) and Secure MIME (S/MIME), I wanted to mention the upcoming Spring 2009 edition of Microsoft Exchange Connections, running March 15–18 in Orlando. As always, admission to Exchange Connections gets you in to the concurrent Windows Connections sessions, so the show is a great opportunity to expand your Windows platform knowledge. Check it out!

Now, on to AD RMS and S/MIME. Last week I outlined the basics of both these technologies. There are some finer distinctions between the two that are worth understanding so you can figure out which technology to use when.

First, keep in mind that S/MIME is intended primarily as a confidentiality and integrity protocol. It doesn't provide any sort of use control or restrictions. Malicious (or careless) recipients can open an S/MIME message—provided they have the correct digital certificate—and after that, they can forward it, print it, and so on. By contrast, AD RMS lets the sender apply restrictions that control what recipients can do with the message, when the message expires, and so forth.

Second, the infrastructure requirements between the two are quite different. S/MIME requires you to have a public key infrastructure (PKI) to issue certificates to each user who will participate. There are many different ways to deploy PKI, with a great variety of complexity and cost, so this is an important point to bear in mind. AD RMS requires that you deploy an AD RMS root server, and it might require additional servers, depending on your network topology. However, AD RMS deployments don't require as much planning to account for cross-certification, which is a point in its favor.

When would you use AD RMS? The typical answer is "when you're a company with valuable information to protect." When you deploy AD RMS with Outlook 2003 or later, your users gain the ability to protect messages. (As a bonus, you can protect messages so that users can't use Reply to All, which could be a great feature to block for large companies).

However, protected messages are somewhat of a hassle to work with. You have to have a compatible client; no Macintosh users need apply, and OWA users have to install the RMS client plug-in for Microsoft Internet Explorer. Windows Mobile 6.1 users can read protected messages with their devices, but the setup is still somewhat finicky. Other Exchange ActiveSync devices can't read AD RMS messages because they lack a client, even though the messages will still synchronize.

The use case for S/MIME is a bit different; companies typically deploy it when they want to secure messages from client desktop to client desktop. As with AD RMS, protected messages can't be read during transport or when stored, unless the client decrypts them and saves them back to the message store. S/MIME is much more broadly deployed than AD RMS, and it's much more interoperable. That makes it a good choice if your primary need is to secure messages sent between users in different organizations.

Both of these technologies have their place, as do other security technologies such as Transport Layer Security (TLS) and IPsec. Deploying them properly can give you a significant boost in security.