The IT world is full of examples of overlapping standards, but in most cases, one standard eventually wins out. Consider SMTP: There have been other protocols for exchanging email over WANs, but SMTP eventually garnered a large enough installed base to become the dominant protocol. There are many other examples of standards that fell by the wayside, unable to keep up. However, in a few areas, there are overlapping standards that complement each other instead of directly competing. One relevant example is the case of Active Directory Rights Management Services (AD RMS) and Secure Multipurpose Internet Mail Extensions (S/MIME), two security protocols for protecting messages against exploitation.
S/MIME is an open Internet standard for digitally signing and encrypting messages using a variety of algorithms and formats. It's intended to provide end-to-end protection for messages by having the sender sign or encrypt the message, and S/MIME protects the message until an authorized recipient opens it. S/MIME provides for three security features: confidentiality, message integrity, and nonrepudiation.
This last feature requires some extra explanation because it's an unfamiliar capability. Saying that a protocol provides nonrepudiation means that a sender can't say "I didn't send that" after a signed message has been sent. Nonrepudiation is a critical capability for electronic commerce, contracting, and so on. S/MIME is primarily a client-based protocol; the client is responsible for protecting the message when it's sent and for opening and verifying it when it's received.
AD RMS is a little different. It's intended to protect both messages and documents by encrypting them, but the protocol's focus is on helping enterprises control how their internal information can be used. AD RMS requires content creators to request content protection from a centralized AD RMS server; when users want to open a protected item, they must obtain permission to do so from the AD RMS infrastructure. RMS-aware clients such as Microsoft PowerPoint, Word, and Outlook are responsible for enforcing the content restrictions (e.g., "do not print," "do not forward") that the creator applied. AD RMS provides confidentiality and use control as its primary features.
These two systems share some outward similarities. They both use encryption to protect messages so that unauthorized people can't read them, even using similar algorithms. They are both oriented toward end-to-end protection, and they both protect messages in such a way that the protection travels with the message instead of in separate metadata. However, there are some important differences that make these two tools complementary for use with Microsoft Exchange Server.
The first significant difference is the question of scope. AD RMS is designed to primarily be used within a single organization, though you can assign permissions to external users who have a Windows Live ID. S/MIME is designed so that you can more easily exchange messages with people across organizations. Because S/MIME is an open Internet standard, there are many S/MIME clients available on different platforms, and interoperability between these clients is generally quite good. AD RMS is supported only on Windows at present, and only some applications support it.
The second main difference is the question of what's protected. AD RMS provides confidentiality and message integrity, as does S/MIME. However, S/MIME has more flexible options for message integrity protection, and it provides nonrepudiation support. That makes it more suitable for passing sensitive data between organizations.
The third important difference between AD RMS and S/MIME is the issue of what the recipient can do with the data. S/MIME assumes a trustworthy recipient gets the message and opens it and can thereafter do with it whatever he or she wants. AD RMS assumes that the recipient is authorized to see the contents of a protected item, but that they might not be trusted to do (or not do) certain things—RMS can be used to restrict unwanted actions.
Both AD RMS and S/MIME can be very useful in the right contexts. In next week's column, I'll highlight some scenarios where each of these technologies can be productively applied.