Compliance and S/MIME

In the comments to a previous post, Clement Kent asks a set of good questions about how to combine compliance requirements with encryption. The bottom line: if you have DCAR (discovery, compliance, archive and recovery) requirements, you have to be very careful with message encryption. You have two basic alternatives:

• Archive the encrypted messages, then make sure that you preserve the key material so you can decrypt them later. This is really, really complicated, since you have to keep the certificates and private keys and CRLs around for however long your DCAR window is. The problem with this approach is that the DCAR system can’t index the messages, so you won’t have a good way to tell whether those messages are in scope when you do a DCAR query. It’s hard enough for most organizations to deploy a PKI in the first place, much less guarantee that they’ll be able to retrieve Joe CEO’s certificate six or seven years from now.
• Add the archive system as a recipient on all encrypted messages. The problem with this approach is that it doesn’t work out of the box; you’ll need to write your own tools. You could accomplish this via a client-side add-in that adds the archive agent as a recipient to any message that’s encrypted, or you could use an event sink that would reject (or quarantine/flag for human attention) any encrypted message that the archiving agent couldn’t read. As a bonus (mis)feature, this approach creates a very valuable target– get the key to the archive account, and you can read all the sooper-secret encrypted traffic.

The US Defense Department chose option 2. Consider the situation where Alice and Bob, both CIA analysts, need to communicate securely. Alice is in Langley, and Bob is in Baghdad. If the CIA mail system allows direct encrypted mail between them, there’s no way for the CIA itself to inspect the message contents. They work around this by using option 2, and also by allowing the mail to travel around Langley and Baghdad unencrypted, but using a server-to-server superencryption like that described in the Open Group‘s S/MIME Gateway Profile.
It’s less clear how you’d preserve DCAR capability with messages protected by Outlook’s IRM features. For messages sent to large groups (like, say, “all employees”), it’s a simple matter to add the archiver to the group; then you just have to ensure that you keep the IRM system up and running for the required length of time. For messages sent to individuals, you’re back to the requirement of writing code to either add the archiving account or to reject the message, but the code has to be smarter because IRM messages lack the easily-recognized S/MIME headers (not to mention that an ordinary message might have an IRM-protected attachment.. but we won’t go there for now).