S/MIME security |
 |
By Paul Robichaux
17 May 2004 | SearchExchange.com |
|
|
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.
S/MIME support is one of Outlook's unheralded important features. (I used to write S/MIME
security software, so I admit to being a little biased.) Outlook's support for S/MIME gives
you end-to-end protection: messages you create can be signed or encrypted on your computer,
and they stay protected as they travel and while they are in the recipient's Exchange
mailbox server. Encrypting, signing, de-crypting, and verifying messages is easy, and
Outlook gives you a great deal of control over the security settings used with particular
certificates. One of the nicest things about Outlook's S/MIME support is that it's
completely integrated (through CryptoAPI) with the rest of the system's crypto-graphic
functions; if you're using certificates or smart cards for access control or other
functions, you will probably be able to use the same certificates with Outlook (as long as
the certificates they contain are marked by the issuer as usable with S/MIME).
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.
|
|
|
|
