Design and Deployment Considerations
That's the easy, front-end part of an S/MIME-based mail security solution. Behind the scenes, you have a lot of thinking to do when you design and deploy an effective mechanism for handling certificates. Ask yourself the following questions to get started.
Can my current mail clients support sufficient S/MIME services? If your current mail clients don't support the full S/MIME feature set that users need (see Table 1 for an overview of the different S/MIME feature sets), you might need to upgrade your mail client software.
If your current mail client doesn't support S/MIME at all, remember that even though users can't create S/MIME-protected messages or read encrypted or opaque signed messages, they can always read clear signed messages. If you use Exchange Server 2003 messaging servers, you can enable S/MIME for users through OWA.
Should I use an internal or commercial CA? S/MIME builds on X.509-formatted digital certificates generated by CAs. To provide S/MIME certificates to your users, you can leverage internal CAs or you can buy certificates from a commercial CA (such as VeriSign at http://www.verisign.com or thawte at http://www.thawte.com). Internal CAs give your organization complete control over the operation of your certificate "engines" and allow you to provide important services such as key archiving and recovery. Because internal CAs require design, deployment, and maintenance of the PKI, they can be costly. For small organizations and organizations that need certificates for a limited set of users or applications, I recommend buying S/MIME certificates from a commercial CA. They are an easy and cheaper option.
How will users enroll for and renew their S/MIME certificates? When you consider an S/MIME deployment, you must plan how users will enroll for and renew their S/MIME certificates. In a Windows 2003 domain environment made up of XP or later clients and containing an integrated Windows PKI, I recommend that you use autoenrollment as the certificate enrollment and renewal method. In Windows 2000 Server domain environments hosting a Windows PKI, users can manually enroll for certificates by using the CA Web enrollment interface or by using the Microsoft Management Console (MMC) Certificates snap-in. If you get your S/MIME certificates from a commercial CA, you must adhere to the enrollment and renewal guidelines that the CA defines.
Do I need a single or a dual S/MIME key pair system? Keeping a central database of private keys can be risky when users use the same key for both encrypting and signing their mail messages. Rogue administrators could extract a user's private key from the archival database and sign mail messages on that user's behalf. To protect users from these threats, most S/MIME client and server software (including Exchange and Outlook) support a dual key pair system. In such a system, a user always has two key pairs: one for signing (the private key from the pair is archived) and one for encrypting (the private key of the pair isn't archived). If your organization doesn't have key archival and recovery requirements, you can use S/MIME with a single key pair. In all other cases, I strongly recommend that you deploy two key pairs for each S/MIME user.
Do I need key archival and recovery services? In many organizations, if users encrypt email messages, the organization's security policy requires key archiving and recovery. A key archival and recovery system keeps a copy of the user's private encryption key in a centralized database. If a user loses his or her private key and no archival and recovery mechanism is available, the encrypted data can't be decrypted.
The need for encryption key archival and recovery services can be one of the reasons to invest in an internal PKI or in a messaging server that offers this service. Exchange Server versions 4.0 through 5.5 offer key archival and recovery services in the Key Management Service (KMS). In Exchange Server 5.5 Service Pack 1 (SP1) and later versions, you can outsource the KMS CA functionality to a Windows CA. In Exchange 2003, the CA and archival and recovery functions have been moved completely to the Windows 2003 CA.
Do my users need advanced private key protection? If your users use S/MIME to sign important mail messages, you must use an advanced private key protection system. Microsoft offers a software-based protection mechanism that can prompt users for a password each time their applications access a private key. The Cryptographic Service Provider screen of the Certificate Request Wizard (Figure 5) lets users set strong private key protection by selecting the Enable strong private key protection option when they enroll for an S/MIME certificate. In the Creating a new RSA exchange key dialog box that appears, select High to enable password protection of the private key.
Other private key protection solutions require that you deploy specialized hardware such as USB tokens, smart cards and smart card readers, or Trusted Platform Module (TPM)-enabled workstations. These advanced solutions definitely offer a high level of private key protection but can be costly to deploy and maintain.
How will I provide up-to-date certificate revocation information to my users? The S/MIME functionality embedded in the Microsoft messaging clients and servers uses a system of certificate revocation lists (CRLs) and CRL distribution points (CRLDPs) to provide users with up-to-date certificate revocation information. CRLs contain the serial numbers of untrustworthy certificates (such as certificates of which the private key has been compromised). CRLDPs point to places from which users can download CRLs. CRLs can be stored in a directory, on a Web server, in a file, or on an FTP share.
Both Outlook 2003 and OWA generate error messages when no up-to-date CRL information is available on the local machine or on one of the CRLDPs. When you design your PKI infrastructure, make sure that you set up multiple CRLDPs, preferably on different storage providers (for example, one in a directory and another one on a Web server). If you exchange S/MIME-secured messages with people outside your organization, you must make sure that the CRLs are also available to them. If you get your certificates from a commercial CA, make sure that you understand its revocation information distribution mechanisms.
S/MIME to the Rescue
S/MIME provides powerful mail security extensions that can greatly benefit your users. Microsoft includes S/MIME functionality in the various Outlook messaging clients and in the Exchange messaging server. Configuring and using S/MIME in Microsoft software is relatively easy, but remember that successful deployment of S/MIME requires you to invest adequate time and effort in planning and designing your certificate infrastructure.