Paul's Down-Home Page

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).

Reader Remek Kocz says:

First of all, thanks for writing Secure Messaging. I’ve been doing a lot of research on Exchange 2K security recently, and your book pretty much filled in all the gaps. The reason I’m writing you is that I have not been able to find an answer to what I thought was a simple question (Usenet wasn’t much help, surprisingly). I’ve been tasked to secure our OWA servers w/SSL, and the issue of certificates came up. Is it possible to obtain a cert from a trusted authority like Verisign and then issue self-issued certificates with a path back to the Verisign one? Being a school district, albeit a large one, we need to look out for every dollar, so I wondered if it would be possible to combine the self-issuing CA &a commercial one. A pure self-issuing CA is not feasible for us, since many people travel without laptops, and there is no way of knowing how they’ll access the OWA servers.

This is a classic case for use of a subordinate CA: you want to create a CA that issues certs to end entities (in this case, your OWA servers; it might equally be used to issue certs to users), and you want that CA’s cert to be issued by a well-known commercial CA. You might think that Verisign, Thawte, and other commercial certificate vendors would provide this as a service, but as far as I can tell, they don’t. Why? Their preference is for you to use them as an issuer, offloading all CA work to them (and, incidentally, paying a per-certificate, per-year fee!) For the specific case you have in mind, Verisign offers their managed PKI service: they issue the certs, and you manage the issuance and revocation process via a web-based admin tool…but you don’t run your own CA. Section 3.1.1 of Verisign’s certification practices statement talks about the process of registering as a non-Verisign sub CA, but I can’t find where you actually do that on their web site. I’ll post more details if I can find a better answer.
Update: BeTrusted‘s OmniRoot service does exactly what you want. Thanks to David Cross for the tip.