The following is tip #4 from "20 Tips on securing Outlook in 20 minutes," excerpted from a chapter in Paul Robichaux's...
book, Secure Messaging with Microsoft Exchange Server 2003 © 2004, published by Microsoft Press. Return to the main page for more tips on this topic.
The reason for the MIME in S/MIME is that the secured content in S/MIME messages is actually made up of Multipurpose Internet Mail Extension (MIME) body parts, as described in Request for Comments (RFC) 1847. That means, for instance, that a plain text message can still contain an attached signature. This is called a clear-signed message, because the message is still readable by clients that don't understand S/MIME signatures. Its opposite, an opaque-signed message, contains the message and signature combined in a single part that cannot be read except by verifying the signature.
The S/MIME version 3 standard, which is what Outlook supports and uses by default, consists of several parts that define various aspects of how clients and servers should create, process, and manipulate secured mail, as follows:
- RFC 3369 describes the Cryptographic Message Syntax (CMS), the format of S/MIME messages. CMS is derived from the older Public Key Cryptography Standards (PKCS) #7 format (RFC 2315), which is why S/MIME-protected messages still appear to have attachments with the .p7m extension that stands for PKCS #7 MIME part. This RFC is interesting primarily because it describes exactly how clients must sign, encrypt, decrypt, and verify messages and how the messages should be structured so that other clients can read them.
- RFC 3370 identifies the algorithms that all S/MIME version 3 software must support to be called S/MIME: Secure Hash Algorithm 1 (SHA-1) and Message Digest-5 (MD5) for hashing, Digital Signature Algorithm (DSA) and RSA for signatures, and RC2 and triple Data Encryption Standard (3DES) for message encryption. Individual implementations are free to add more algorithms to this set, provided they properly identify which algorithms a particular message uses so the recipient can figure it out.
- RFC 2632 describes certificate handling for S/MIME-compatible software. It specifies when and how clients should check for certificate revocation and expiration, how they should handle unknown certificate authority (CA)-specific extensions, and so forth.
- By its own admission, RFC 2633 "defines how to create a MIME body part that has been cryptographically enhanced according to CMS, which is derived from PKCS #7. This memo also defines the application/pkcs7-mime MIME type that can be used to transport those body parts."
As a messaging administrator, you might not ever want to read these RFCs, but they can give you some useful insight into why S/MIME clients act the way they do in some circumstances.
Outlook provides complete S/MIME version 3 support, plus some additional features defined in RFC 2634, including digitally signed message receipts, security labels (like secret or confidential), and a few other features of interest primarily to users of the Defense Messaging System (DMS), which I'm not going to cover in this book.
Get more "20 Tips on securing Outlook in 20 minutes!" Return to the main page.
About the author: Paul Robichaux is a partner at 3sharp LLC, author of several books on Exchange, Windows, and security, a Microsoft MVP for Exchange Server and a frequent speaker and presenter at IT industry conferences. He's written software for everyone from the U.S. National Security Agency to scientists flying their experiments aboard the Space Shuttle, fixed helicopters in the desert and spent way too much time playing video games.