HEPKI-TAG S/MIME Project Requirements

PKI-lite S/MIME Experiment Requirements

Document: hepki-tag-pkilite-smime-6.html 
Editor: James Jokl 
Date: March 26, 2002
Comments to: hepki-tag@internet2.edu

Project Overview
1. Phase I
  1. Focus on user-to-user applications for signed and encrypted email using standardly available email clients.
  2. Participants: campus technical staff
  3. Certificates based on the PKI-lite profile
    Certificates used in the S/MIME project should comply with the PKI-lite certificate profiles. This does not preclude campuses with more complex profiles or higher assurance CAs from participating. The PKI-lite profiles are designed to be flexible and set minimum requirements. The 13 month maximum validity period specified in the PKI-lite profile is waived for this project.
  4. No requirement for a specific level of assurance
  5. End user documentation will be developed during this phase
2. Phase II
  1. Focus both on user-to-user applications and on user-to-application and application-to-user scenarios. Some potential applications are:
    1. A central application sending signed notifications to users
    2. Mailing list access control via signed messages
    3. Workflow based on a user sending a signed message to an application
    4. etc
  2. Participants: technical staff and an assortment of normal campus users
  3. Certificates based on the PKI-lite profile
    Certificates used in the S/MIME project should comply with the PKI-lite certificate profiles. This does not preclude campuses with more complex profiles or higher assurance CAs from participating. The PKI-lite profiles are designed to be flexible and set minimum requirements. The 13 month maximum validity period specified in the PKI-lite profile is waived for this project.
  4. PKI-lite assurance certificates
  5. End user documentation will be tested and refined during this phase of the project.
  6. Along with Campus CAs, CREN will be able to provide EE certs for project participants using the PKI-lite profile and providing PKI-lite levels of assurance.
Public Key Infrastructure (Required)
1. Access to a CA Each participating institution must have access to a Certification Authority that will issue End Entity certificates using the PKI-Lite Certificate Profile to their end-users. Some options include:
  1. Institutional CA
    A Certification Authority run by the school using available software such as OpenSSL, Win2K, Netscape CA software, etc or a contract with a commercial firm to provide CA services to the institution.
  2. Certificates from the CREN test CA
  3. Certificates from the HEPKI-Demo CA
  4. Certificates from the Black Helicopter CA
  5. Certificates from the Dartmouth test CA
2. Institutional / Organizational Root Certificate Repository
  A way for testers to easily download the the institutional root certificates for the people they will correspond with. The demonstration HEPKI Repository may be sufficient for the project.
Public Key Infrastructure (Optional)
1. Ability to publish certificates in campus LDAP directory
  Publishing End Entity certificates in the campus LDAP directory facilitates the use of encrypted e-mail. The directory eliminates the need to exchange certificates via signed email before encrypted email can be used. Schools probably don't want to implement this feature if it is difficult in their environment.
Supported E-Mail Clients
The pilot project will focus on the use of commonly available standards-based S/MIME capable email clients. The project will develop support and verify interoperability between the following email clients:
1. Netscape Communicator (Messenger ver 4.7)
  1. Windows
  2. Macintosh
  3. Unix
2. Mozilla
  1. Windows
  2. Macintosh
  3. Unix
3. Microsoft Outlook (Outlook 2000 or greater)
4. Microsoft Outlook Express (version 5.5 or greater)
5. Eudora with the Tumbleweed S/MIME plug-in
6. Hopefully some Entrust plugins and something for Macintosh and Unix also
Documentation
1. Overview document
  1. Why S/MIME
    1. Email forgery and associated campus problems
    2. Privacy - both during transmission and while stored on servers
    3. Legacy interoperability: email signed in the normal (non-opaque) way can still be read using non-S/MIME capable clients
    4. Why not PGP: popular email clients support S/MIME
      Lack of significant acceptance of PGP especially given the time it has been available for use.
  2. Goals
    1. Demonstrate inter-campus interoperability
    2. Document client interoperability and problems encountered
    3. Estimate the level of effort needed for the project and for campus-wide deployments.
    4. Prepare information that will make it easier for new sites to join the project.
    5. Verify that the PKI-lite Certificate Profile is sufficient to support S/MIME applications.
  3. Anticipated participants
    1. Initially technical staff at participating institutions who won't need help.
    2. A later phase of the project will expand to include technical admins and other staff
  4. Planned reporting
2. Documentation on configuring and using each supported client
  1. Client configuration for PKI
  2. Client use - signing
  3. Known problems (e.g. the Outlook Key Usage problem)
  4. Information on any export controls on clients
  5. Level of S/MIME support (v2/v3)
  6. Client "From" address matching certificate's subject email address
3. Certificate and private key management
  1. The certificate stores used by the various email clients.
  2. How to move the certificate and associated private key to a different store
  3. Protecting your private key
  4. Single certificates v.s. using a different cert on each of a user's machines.
  5. The use of separate signing and encryption certificates. There is doubt about the long term viability of clients that do not support the use of separate signing and encryption certificates.
  6. Participating sites are strongly encouraged to ask individuals to use a single set of certificates and associated private keys on all of the computers that they will be using during the test. We are trying to minimize complexity and decryption can be tedious if your users need to search for the proper private key needed to decrypt a message.
4. Known issues on encrypted email
  1. Key Escrow
  2. Inbox
  3. Folders
  4. Encryption on cc: me
5. Privacy and Digital Certificates in an S/MIME Context
  Something to convey the idea to users that presenting their certificate is like showing an ID card. Not really an issue for e-mail since there is an expectation with signed email that you are trying to convey your identity. Is a subscriber agreement sufficient notification?
Campus Staffing Expectations
1. Project start-up requirements
2. Estimated longer-term support load
3. Project will attempt to capture and document the required level of effort.
4. Is the pilot mostly for people who don't need help?
Project Deliverables
1. Documentation
2. Best practices
3. Recommendations
4. Poor practices - things not to do
5. Learnings:
  1. Major problems encountered with clients and infrastructure.
  2. Collection of perceptions on general ease of use
  3. Unintended consequences