Plan for e-mail messaging cryptography in Outlook 2010
Applies to: Office 2010
Topic Last Modified: 2011-08-05
Microsoft Outlook 2010 supports security-related features to help users send and receive cryptographic e-mail messages. These features include cryptographic e-mail messaging, security labels, and signed receipts.
Note
To obtain full security functionality in Microsoft Outlook, you must install Outlook 2010 with local administrative rights.
In this article:
About Cryptographic messaging features in Outlook 2010
Managing cryptographic digital IDs
Security labels and signed receipts
Configuring Outlook 2010 cryptographic settings
Configuring additional cryptography settings
About Cryptographic messaging features in Outlook 2010
Outlook 2010 supports cryptographic messaging features that enable users to do the following:
Digitally sign an e-mail message. Digital signing provides nonrepudiation and verification of contents (the message contains what the person sent, without any changes).
Encrypt an e-mail message. Encryption helps ensure privacy by making the message unreadable to anyone other than the intended recipient.
Additional features can be configured for security-enhanced messaging. If your organization provides support for these features, security-enhanced messaging enables users to do the following:
Send an e-mail message that uses a receipt request. This helps verify that the recipient is validating the user's digital signature (the certificate that the user applied to a message).
Add a security label to an e-mail message. Your organization can create a customized S/MIME V3 security policy that adds labels to messages. An S/MIME V3 security policy is code that you add to Outlook. It adds information to the message header about the sensitivity of the message. For more information, see Security Labels and signed receipts later in this article.
How Outlook 2010 implements cryptographic messaging
The Outlook 2010 cryptography model uses public key encryption to send and receive signed and encrypted e-mail messages. Outlook 2010 supports S/MIME V3 security, which allows users to exchange security-enhanced e-mail messages with other S/MIME e-mail clients over the Internet or intranet. E-mail messages encrypted by the user's public key can be decrypted only by using the associated private key. This means that when a user sends an encrypted e-mail message, the recipient's certificate (public key) encrypts it. When a user reads an encrypted e-mail message, the user's private key decrypts it.
In Outlook 2010, users are required to have a security profile to use cryptographic features. A security profile is a group of settings that describes the certificates and algorithms used when a user sends messages that use cryptographic features. Security profiles are configured automatically if the profile is not already present when:
The user has certificates for cryptography on his or her computer.
The user begins to use a cryptographic feature.
You can customize these security settings for users in advance. You can use registry settings or Group Policy settings to customize Outlook to meet your organization's cryptographic policies and to configure (and enforce, by using Group Policy) the settings that you want in the security profiles. These settings are described in Configuring Outlook 2010 cryptographic settings later in this article.
Digital IDs: A combination of public/private keys and certificates
S/MIME features rely on digital IDs, which are also known as digital certificates. Digital IDs associate a user's identity with a public and private key pair. The combination of a certificate and private/public key pair is called a digital ID. The private key can be saved in a security-enhanced store, such as the Windows certificate store, on the user's computer, or on a Smart Card. Outlook 2010 fully supports the X.509v3 standard, which requires that public and private keys are created by a certification authority in an organization, such as a Windows Server 2008 computer that is running Active Directory Certificate Services or by a public certification authority such as VeriSign. For information about which option might be best for your organization, see Digital certificate: Self-signed or issued by CAs in Plan digital signature settings for Office 2010.
Users can obtain digital IDs by using public Web-based certification authorities such as VeriSign and Microsoft Certificate Services. For more information about how users can obtain a digital ID, see the Outlook Help topic Get a digital ID (https://go.microsoft.com/fwlink/p/?LinkId=185585). As an administrator, you can provide digital IDs to a group of users.
When certificates for digital IDs expire, users typically must obtain updated certificates from the issuing certification authority. If your organization relies on Windows Server 2003 Certificate Authority (CA) or Active Directory Certificate Services (AD CS) in Windows Server 2008 for certificates, Outlook 2010 automatically manages certificate update for users.
Managing cryptographic digital IDs
Outlook 2010 provides ways for users to manage their digital IDs — the combination of a user's certificate and public and private encryption key set. Digital IDs help keep users' e-mail messages secure by letting them exchange cryptographic messages. Managing digital IDs includes the following:
Obtaining a digital ID. For more information about how users can obtain a digital ID, see the Outlook Help topic Get a digital ID (https://go.microsoft.com/fwlink/p/?LinkId=185585).
Storing a digital ID, so you can move the ID to another computer or make it available to other users.
Providing a digital ID to other users.
Exporting a digital ID to a file. This is useful when the user is creating a backup or moving to a new computer.
Importing a digital ID from a file into Outlook. A digital ID file might be a user's backup copy or might contain a digital ID from another user.
Renewing a digital ID that has expired.
A user who performs cryptographic messaging at more than one computer must copy his or her digital ID to each computer.
Places to store digital IDs
Digital IDs can be stored in three locations:
Microsoft Exchange Global Address Book Certificates generated by CA or by AD CS are automatically published in the global address book (GAL). Externally generated certificates can be manually published to the global address book. To do this in Outlook 2010, on the File tab, click Options, and then click Trust Center. Under Microsoft Outlook Trust Center, click Trust Center Settings. On the E-mail Security tab, under Digital IDs (Certificates), click the Publish to GAL button.
Lightweight Directory Access Protocol (LDAP) directory service External directory services, certificate authorities, or other certificate providers can publish their users' certificates through an LDAP directory service. Outlook allows access to these certificates through LDAP directories.
Microsoft Windows file Digital IDs can be stored on users' computers. Users export their digital ID to a file from Outlook 2010. To do this, on the File tab, click Options, and then click Trust Center. Under Microsoft Outlook Trust Center, click Trust Center Settings. On the E-mail Security tab, under Digital IDs (Certificates), click the Import/Export button. Users can encrypt the file when they create it by providing a password.
Providing digital IDs to other users
If a user wants to exchange cryptographic e-mail messages with another user, they must have each other's public key. Users provide access to their public key through a certificate. There are several ways to provide a digital ID to other users, including the following:
Use a certificate to digitally sign an e-mail message. A user provides his or her public key to another user by composing an e-mail message and digitally signing the message by using a certificate. When Outlook users receive the signed message, they right-click the user's name on the From line, and then click Add to Contacts. The address information and the certificate are saved in the Outlook user's contacts list.
Provide a certificate by using a directory service, such as the Microsoft Exchange Global Address Book. Another alternative is for a user to automatically retrieve another user's certificate from an LDAP directory on a standard LDAP server when he or she sends an encrypted e-mail message. To gain access to a certificate in this manner, users must be enrolled in S/MIME security with digital IDs for their e-mail accounts.
A user can also obtain certificates from the global address book.
Importing digital IDs
Users can import a digital ID from a file. This is useful, for example, if a user wants to send cryptographic e-mail messages from a new computer. Each computer from which the user sends cryptographic e-mail messages must have the user's certificates installed. Users export their digital ID to a file from Outlook 2010. To do this, on the File tab, click Options, and then click Trust Center. Under Microsoft Outlook Trust Center, click Trust Center Settings. On the E-mail Security tab, under Digital IDs (Certificates), click the Import/Export button.
Renewing keys and certificates
A time limit is associated with each certificate and private key. When the keys provided by CA or by AD CS approach the end of the designated time period, Outlook displays a warning message and offers to renew the keys. Outlook prompts the user, offering to send the renewal message to the server on each user's behalf.
If users do not choose to renew a certificate before it expires, or if they use another certification authority instead of in CA or AD CS, the user must contact the certification authority to renew the certificate.
Security labels and signed receipts
Outlook 2010 includes support for S/MIME V3 Enhanced Security Services (ESS) extensions about security labels and signed receipts. These extensions help you provide security-enhanced e-mail communications within your organization and to customize security to fit your requirements.
If your organization develops and provides S/MIME V3 security policies to add custom security labels, the code in the security policies can enforce attaching a security label to an e-mail message. Two examples of security labels include the following:
An Internal Use Only label might be implemented as a security label to apply to mail that should not be sent or forwarded outside your company.
A label can specify that certain recipients cannot forward or print the message, if the recipient also has the security policy installed.
Users can also send security-enhanced receipt requests with messages to verify that the recipients recognize the user's digital signature. When the message is received and saved (even if it is not yet read) and the signature is verified, a receipt implying that the message was read is returned to the user's Inbox. If the user's signature is not verified, no receipt is sent. When the receipt is returned, because the receipt is also signed, you have verification that the user received and verified the message.
Configuring Outlook 2010 cryptographic settings
You can control many aspects of Outlook 2010 cryptography features to help configure more secure messaging and message encryption for your organization by using the Outlook 2010 Group Policy template (Outlook14.adm). For example, you can configure a Group Policy setting that requires a security label on all outgoing mail or a setting that disables publishing to the global address list. You can also use the Office Customization Tool (OCT) to configure default settings, which enables users to change the settings. Also, there are cryptography configuration options that can only be configured by using registry key settings.
For more information about how to download the Outlook 2010 adminsitrative template, and about other Office 2010 Administrative Templates, see Office 2010 Administrative Template files (ADM, ADMX, ADML) and Office Customization Tool. For more information about Group Policy, see Group Policy overview for Office 2010 and Use Group Policy to enforce Office 2010 settings.
For more information about the OCT, see Office Customization Tool in Office 2010.
You can lock down the settings in the following table to customize cryptography. In the OCT, on the Modify user settings page, these settings are under Microsoft Outlook 2010\Security\Cryptography. In Group Policy, these settings are under User Configuration\Administrative Templates\Microsoft Outlook 2010\Security\Cryptography.
| Cryptography option | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
Always use TNEF formatting in S/MIME messages |
Always use transport neutral encapsulation format (TNEF) for S/MIME messages instead of the format specified by the user. |
||||||||
Do not check e-mail address against address of certificates being used |
Do not verify user's e-mail address by using address of certificates that are used for encryption or signing. |
||||||||
Do not display 'Publish to GAL' button |
Disable the Publish to GAL button on the E-mail Security page of the Trust Center. |
||||||||
Do not provide Continue option on Encryption warning dialog boxes |
Disable the Continue button on encryption settings warning dialog boxes. Users will not be able press Continue to send the message. |
||||||||
Enable Cryptography Icons |
Display Outlook cryptography icons in the Outlook user interface (UI). |
||||||||
Encrypt all e-mail messages |
Encrypt outgoing e-mail messages. |
||||||||
Ensure all S/MIME signed messages have a label |
Require all S/MIME-signed messages to have a security label. Users can attach labels to e-mail messages in Outlook 2010. To do this, on the Options tab, in the More Options group, under Security, click the Security Settings button. In the Security Properties dialog box, select Add digital signature to this message. Under Security Label for Policy, select a label. |
||||||||
Fortezza certificate policies |
Enter a list of policies allowed in the policies extension of a certificate that indicate the certificate is a Fortezza certificate. List policies separated by semicolons. |
||||||||
Message formats |
Choose message formats to support: S/MIME (default), Exchange, Fortezza, or a combination of these formats. |
||||||||
Message when Outlook cannot find the digital ID to decode a message |
Enter a message to display to users (maximum 255 characters). |
||||||||
Minimum encryption settings |
Set to the minimum key length for an encrypted e-mail message. Outlook will display a warning message if the user tries to send a message by using an encryption key that is below the minimum encryption key value set. The user can still choose to ignore the warning and send by using the encryption key originally chosen. |
||||||||
Replies or forwards to signed/encrypted messages are signed/encrypted |
Enable to turn on signing/encryption when replying/forwarding a signed or encrypted message, even if the user is not configured for S/MIME. |
||||||||
Request an S/MIME receipt for all S/MIME signed messages |
Request a security-enhanced receipt for outgoing signed e-mail messages. |
||||||||
Require SUITEB algorithms for S/MIME operations |
Use only Suite-B algorithms for S/MIME operations. |
||||||||
Required Certificate Authority |
Set the name of the required certification authority (CA). When a value is set, Outlook disallows users from signing e-mail by using a certificate from a different CA. |
||||||||
Run in FIPS compliant mode |
Require Outlook to run in FIPS 140-1 mode. |
||||||||
S/MIME interoperability with external clients: |
Specify the behavior for handling S/MIME messages: Handle internally, Handle externally, or Handle if possible. |
||||||||
S/MIME receipt requests behavior |
Specify an option for how S/MIME receipt requests are handled:
|
||||||||
Send all signed messages as clear signed messages |
Send signed e-mail messages in clear text. |
||||||||
Sign all e-mail messages |
Require digital signatures on all outgoing e-mail messages. |
||||||||
Signature Warning |
Specify an option for when signature warnings display to users:
|
||||||||
URL for S/MIME certificates |
Provide a URL at which users can obtain an S/MIME receipt. The URL can contain three variables (%1, %2, and %3), that will be replaced by the user's name, e-mail address, and language, respectively. When you specify a value for URL for S/MIME certificates, use the following parameters to send information about the user to the enrollment Web page.
For example, to send user information to the Microsoft enrollment Web page, set the URL for S/MIME certificates entry to the following value, including the parameters:
For example, if the user's name is Jeff Smith, e-mail address is someone@example.com, and user interface language ID is 1033, the placeholders are resolved as follows:
|
The settings in the following table are in Group Policy under User Configuration\Administrative Templates\Microsoft Outlook 2010\Security\Cryptography\Signature Status dialog box. The OCT settings are in corresponding locations on the Modify user settings page of the OCT.
| Cryptography option | Description |
|---|---|
Attachment Secure Temporary Folder |
Specify a folder path for the Secure Temporary Files Folder. This overrides the default path and we do not recommend it. If you must use a specific folder for Outlook attachments, we recommend that:
|
Missing CRLs |
Specify the Outlook response when a certificate revocation list (CRL) is missing: warning (default) or display error. Digital certificates contain an attribute that shows where the corresponding CRL is located. CRLs contain lists of digital certificates that have been revoked by their controlling certification authorities (CAs), typically because the certificates were issued incorrectly or their associated private keys were compromised. If a CRL is missing or unavailable, Outlook cannot determine whether a certificate has been revoked. Therefore, an incorrectly issued certificate or one that has been compromised might be used to gain access to data. |
Missing root certificates |
Specify the Outlook response when a root certificate is missing: neither error nor warning (default), warning or display error. |
Promote Level 2 errors as errors, not warnings |
Specify the Outlook response for Level 2 errors: display error or warning (default). Potential Error Level 2 conditions include the following:
|
Retrieving CRLs (Certificate Revocation Lists) |
Specify how Outlook behaves when CRL lists are retrieved:
|
Configuring additional cryptography settings
The following section provides additional information about configuration options for cryptography.
Security policy settings for general cryptography
The following table shows additional Windows registry settings that you can use for your custom configuration. Theses registry settings are located in HKEY_CURRENT_USER\Software\Microsoft\Cryptography\SMIME\SecurityPolicies\Default. There is no corresponding Group Policy.
| Registry entry | Type | Value | Description |
|---|---|---|---|
ShowWithMultiLabels |
DWORD |
0, 1 |
Set to 0 to attempt to display a message when the signature layer has different labels set in different signatures. Set to 1 to prevent display of message. Default is 0. |
CertErrorWithLabel |
DWORD |
0, 1, 2 |
Set to 0 to process a message that has a certificate error when the message has a label. Set to 1 to deny access to a message that has a certificate error. Set to 2 to ignore the message label and grant access to the message. (The user still sees a certificate error.) Default is 0. |
See Also
Concepts
Plan for security and protection in Outlook 2010
Plan security for Office 2010
Plan digital signature settings for Office 2010