Eudora S/MIME Feedback

These notes have been created to assist Qualcomm as they scope the work
involved in a potential project to S/MIME-enable Eudora.  Each of the major
items is prioritized as High, Medium, and Low priority.


1) Fundamental Assumptions
   a) The HEPKI-TAG group would like to schedule a conference call with
      the appropriate people at Qualcomm to discuss these items and better
      understand any complications that might arise from any of these
      recommendations.
   b) (H) There is a strong preference that Eudora support S/MIME functionality on
      all platforms.


2) Basic PKI Issues
   a) (H) Preference is to use the native Operating System certificate
      and key store to ease support issues.
   b) How should other user certificates be stored and made available
      for sending encrypted messages when received in an S/MIME message
      - (H) capture and store certificates automatically and/or ask 
        via a user preference setting.
      - no strong preference for where the certificates are stored
      - (H) the user should be able to edit and manage this store
   c) (L) Certificate revocation issues
      It would be nice if Eudora would:
      - honor CRL distribution points in certificates if enabled
        in the Eudora or Operating System configuration
      - cache CRLs and OCSP responses for off-line use
      - enable/disable checking of CRLs via user interface
   d) (L) Dual-key support for separate signing and encryption certs/keys.
      - however, we know that there will be problems at some sites if this
        capability does not exist.  HEPKI-TAG feels that this problem will
        grow over time.
   e) (M) A user should be able to trust an individual random received certificate
      without having to trust the certificate's root and thus the whole remote
      PKI.

3) Signed email 
   a) (H) Support for both signed and encrypted email is needed
   b) Opaque Signed Messages
      - (H) Eudora should be able to display received Opaque Signed messages
      - (L) Eudora should be able to create an Opaque Signed message

4) Encrypted email (note: section 4d below needs discussion, recasting)
   a) (H) Support for both signed and encrypted email is needed
   b) (H) A user controlled option that would cause the sent-mail folder
      to optionally be stored in unencrypted form is desired
   c) (M) A user controlled option that would cause messages in folders
      to be stored in unencrypted form is desired
   d) LDAP can be difficult to use on an inter-institutional basis to find
      user certificates but can be very useful on campus.  Our recommended
      LDAP behavior is:
         (M) a manual search with the certificate being stored in the
         local address book or in the certificate store described
         in Section 1B above
   e) (H) We recommend that Eudora support the intersection set of 
      commonly supported ciphers and MACs.  All common S/MIME
      capable email clients support 3DES and SHA-1.  Additional information
      is available in RFC-3370.

5) User interface
   a) (H) The user interface should allow the person receiving a 
      message to see the message content (if at all possible) regardless
      of the status of the signature verification.
   b) (H) The sign and encrypt buttons should be part of the standard message
      composition tool bar and should indicate whether the current message will
      be encrypted or signed when sent.
   c) (M) User preferences for signing and/or encrypting messages
      - There should be a preference setting to sign and/or encrypt all messages
      - If a message can't be encrypted for lack of a public key, a warning should
        be produced but the user should have the option to send the message anyway.
        This warning should be the default but possibly provide the ability to 
        disable it via preferences settings.
      - Address Book records should include an option to always (or never) encrypt
        and/or sign messages to that recipient.  This should override the Eudora
        system default setting. The user interface should provide a way to override
        this setting via the the sign and encrypt buttons.
   d) (H) Make it very obvious if there are any S/MIME problems
      with a received message
   e) (M) Received messages where the mail client is unable to determine the
      correct status should be displayed differently from messages that
      are truly bad.  For example, a message using an expired certificate
      or if a CRL is unavailable should be displayed with some type of
      warning as opposed to a message with a bad signature for which
      it should be obvious that there is a serious problem with
      the message.
   f) (H) The user interface should display a warning of some type when rendering
      active content (e.g., displaying a date macro, rendering a URL, running
      javascript, etc) in a signed message.
   g) (M) The user interface should provide a mechanism to view the raw text
      of a message on both send and receive.
   h) (L) We suggest that S/MIME failures and warnings be included in the Eudora
      filtering mechanism so that user can configure their client to deal with these
      as they see fit.


6) On the normal question of enforcing that the email From: line matches
   the email address in the user's certificate
   a) (H) Client should not enforce this for sending messages.  Some type of
      warning to the user would be nice.
   b) (H) The user interface should display a warning when the FROM address
      of a received message does not match the email address in the certificate.
   c) (M) Recommend that the client display the Subject CN and email address
      from the certificate when email From: line != the email address in the
      certificate used to sign the message.

7) (H) It is more important to us that Eudora is able to verify signatures
   for messages stored in the inbox, sentmail folder, general folders, etc, than
   it is that Eudora retain its behavior of automatically splitting attachments
   out of received messages and storing them in a different location.