Document: draft-internet2-HEPKI-TAG-Outlook-OE-SMIME-Challenges-2.html
Editor: James Jokl
Date: December 17, 2002
Comments to: hepki-tag@internet2.edu
Revision: 2

Introduction
Microsoft's Outlook and Outlook Express products are PKI enabled and include full support for signed and encrypted electronic mail using S/MIME. However, there are a few details about the implementation of S/MIME in these clients that hinders its use and acceptance for large-scale email deployments at higher education institutions. This document is not an attempt to criticize Microsoft or the Outlook email clients. Most of the challenges described here also exist in other S/MIME capable clients. Our goal is to describe some areas where we believe that Microsoft could make some small changes and greatly increase the usability of S/MIME in higher education environments. A few of the challenges described in this document focus on the special issues associated with encrypted messages. Most schools see many possible applications for the use of encrypted email but worry that it will be too hard to support with the existing behavior of most email clients. Some of the suggestions described here would significantly reduce the problems associated with adequately supporting the use of encrypted email.

Challenges

1. Encrypted Messages and Folders
   Outlook and Outlook Express store all messages sent or received using encryption in encrypted form. This is true for received messages in the inbox, for messages in the sent items folder, and for messages moved to other folders by the user. While this behavior certainly maximizes the protection of messages sent using encryption, it also raises the question of how users will be able to view archived email in the future. Even if a PKI is deployed that fully supports escrow of the private encryption key, the chances that an institution would be able to provide the key many years in the future or that software would still be available to use the key to decrypt the message is questionable. We believe that a user selectable option or perhaps even a registry setting that causes Outlook to store messages in user folders and the sent items folder in unencrypted form would greatly enhance the acceptance rate of the use of encrypted email. The default behavior of the client should continue to be that all encrypted messages are stored in folders in encrypted form.
   

2. Specifying Personal Certificates
   Some schools are concerned about the use of encrypted email. In some cases the issue is based on policies regarding open communications and requirements to be able to produce documents that are subject to Freedom of Information requests. Other schools are concerned that archives of encrypted email will become unavailable over time, as the associated private keys are lost. This can be true even in environments where encryption key escrow is supported depending on data archiving policies. In order to prevent accidental encryption of messages, some schools have modified their certificate profile so that the Key Usage field in end user certificates does not allow encryption.

   The Outlook window that is used to specify which certificate should be used for signing and which certificate should be used for encryption has a peculiar property in that you are unable to specify a signing certificate without also selecting an encryption certificate. This precludes the use of Outlook in environments where signed email would be a valuable tool but where encrypted email poses too many risks to the institution to be supported. A modification to Outlook that enabled the use of a signing certificate without an encryption certificate would be of significant benefit to some higher education institutions.
   

3. CRL Support
   Support for checking Certificate Revocation Lists (CRLs) is configured through operating system level changes and does not appear to be something that can be enabled or disabled from within the email client. We believe that this will complicate deployments at some institutions that need to use CRLs to verify signed email.
   

4. Address Book Support
   The transmission of encrypted email requires that the sender have a copy of the recipient's current encryption certificate in their local address book. This complicates sending the first encrypted message to a new recipient. Also, every time a recipient changes to a new encryption certificate, they need to notify all of the parties with whom they regularly correspond to update their address books. A setting in the email client that causes the client to first check a campus LDAP server for the recipient's certificate (if on-line) before using any certificate in the local address book would greatly simplify the use of encrypted email.

   Address book and LDAP search interactions with S/MIME could be generalized into into a single radio button with three settings depending on user preference.

   1. The current behavior where users manually search the LDAP directory and save certificates into their address book.
   2. A LDAP-primary mode where the LDAP directory is searched first and the local address book is only consulted if the LDAP search fails. The address book is not updated by the automatic LDAP search.
   3. An automatic mode where the LDAP directory is searched first and the local address book is automatically updated based on the results of the LDAP search. The address book is used when the LDAP search fails.
   We recommend that the existing behavior be the default configuration.
   

5. Old Issues
   Two other issues were found at various stages in our testing that may or may not already have been fixed:
   1. Outlook Express is able to send opaque signed messages but is not able to verify the signature on the messages that it sends. Other clients are able to read and verify the signature.
   2. We believe that at least one version of Outlook or Outlook Express is unable to verify a signature after the signing certificate has expired. We are checking to see if we can locate more details on this question.