CURRENT_MEETING_REPORT_ Reported by Steve Kent/BBN Minutes of the Privacy Enhanced Mail Working Group (PEM) PEM Implementation Status Report o TIS TIS/PEM is now available via anonymous FTP and the distribution includes CA software. The TIS UK office is working on a commercial PEM implementation to be made available in Europe. o MIT TechMail with PEM, a Mac PEM implementation integrated with a Mac e-mail system, will be available very soon via anonymous FTP. TechMail requires a POP3 server and has been shown to interoperate with TIS/PEM. Ray Lau, a well-known Mac software developer, has developed a stand-alone version of PEM software for the Mac which may be available soon. o PASSWORD Project Three Unix PEM implementations are now available, and a fourth is on the way as a result of this EC-sponsored project. The implementations are from UCL, Cambridge University, INRIA, and GMD. All can make use of X.500 directories and all include CA software. All the implementations interoperate with one another and there have been some interworking tests with TIS/PEM. The UCL version is ``somewhat'' integrated with MH and runs on a SPARC now. The GMD version is part of a larger security tool kit, using a variety of algorithms, and secure (strong authentication) X.500 operations. The GMD implementation is a standalone version that is not integrated into an e-mail system, although it is integrated with X.500 directory access code to fetch certificates and CRLs. It will be available via anonymous FTP (subject to COCOM restrictions). There are plans to establish a PCA for academic users within Germany. The Cambridge version supports symmetric key management as well as asymmetric key management (using RSA). The Cambridge version is the subject of experimentation with other algorithm suites, e.g., DSA and SHA. It also works without access to a directory server. o COST (Sweden) This commercial PEM implementation runs on DEC and Sun workstations, includes CA software, and includes a centralized certificate server for all COST/PEM users. COST intends to run its own PCA. COST/PEM is now undergoing beta testing at universities in Dublin and Stockholm. They are performing interoperability tests with TIS. A smart card version is being developed. o RSADSI A new TIPEM (commercial product) version is in beta now and should be available in eight to twelve weeks. The Certificate Issuing Systems (a commercial product) software and hardware will be available in six to eight weeks. A description of the RSADSI plans for operating a low-assurance PCA with two CAs will be available very soon. One CA (a free service) under this PCA will be a PERSONA CA and it is now operating on a trial basis; a second (non-PERSONA) CA will become operational soon along with a policy statement available via FTP. A commercial PCA, using the CIS noted above, will be available soon, and the policy for that PCA also will be available soon. MIME-PEM Discussion It was the intent of this PEM Working Group meeting to review the latest technical proposal (Internet-Draft) for MIME-PEM integration, as announced in the agenda distributed several weeks prior to the meeting. John Linn and Jeff Schiller were asked to review this Internet-Draft and prepare comments for this meeting. Unfortunately, the Internet-Draft available immediately prior to the meeting did not reflect changes discussed at the last working group meeting and in subsequent pem-dev mailing list discussion. Thus no substantive progress was made on this topic. Both John and Jeff expressed concern about the continued presence of inline ``optional'' fields to indicate the PEM processing to be applied, or to indicate the PEM processing that has been applied to a message. They also expressed concern about ``distinguished encoding'' problems that may arise in complex MIME messages where a signature might encompass MIME headers embedded in these complex messages. Both observed that one possible means of simplifying the MIME-PEM ``integration problem'' is to treat an RFC 1421 ``message'' as a body part to be carried by MIME. This might not offer all of the flexibility of the recent proposals, but it would significantly simplify both processing and backward compatibility for RFC 822-PEM implementations. Steve Crocker presented several technical points related to the structure of MIME-PEM messages, based on a very recent meeting with Marshall Rose. There was agreement that signatures on complex MIME objects cannot be effected as previously proposed, and that new application type MIME objects were required to ``protect'' signed data from possible manipulation by MIME relays. He agreed that representing PEM messages as application context types would allow RFC 1421 data to be a body part, as suggested above. An analysis by Steve Crocker and Marshall suggested that a (MIME) message reader can easily distinguish among a vanilla text message, a MIME message, or a PEM-MIME message. Disambiguation would require introduction of an additional blank line into the RFC 1421 message format. However, if an RFC 1421 message were to pass through an intermediate MIME relay, it might be transformed in a way that would make it ambiguous as to whether this was initially an RFC 1421 message or initially a MIME-PEM message. There was no resolution of these issues. There was agreement that a new MIME-PEM Internet-Draft must be written to reflect the recent improved understanding of these problems, and to reflect the comments of the previous PEM Working Group meetings. A proposal for a simple, MIME encapsulation of RFC 1421 messages may be developed, but no authors were identified. Certificate Name Discussion At the previous PEM Working Group meeting, Steve Crocker initiated a discussion of the form of names that should appear in certificates used in PEM. He advocated the use of domain name system (DNS) mailbox names in lieu of distinguished names (DNs). This discussion took the form of several hand-written slides that were reported upon in the meeting minutes, but there was no written follow-up on the pem-dev mailing list. In response to this previous presentation, Steve Kent assembled material to compare the use of DNS names and DNs. Due to time constraints, only some of this material was presented during the meeting. All of the material is included at the end of these minutes. This material argues that many (though not all) of the objections previously raised to the use of DNs can be addressed through good PEM implementation practice and that the use of DNs offers a number of advantages relative to the use of DNs. Certification System Discussion At the previous PEM Working Group meeting, Steve Crocker also initiated a discussion of the concept of relaxing some of the constraints imposed by the PEM certificate management system (RFC 1422). This discussion took the form of several hand-written slides that were reported upon in the meeting minutes, but there was no written follow-up on the pem-dev mailing list. In response to this previous presentation, Steve Kent assembled material to review some of the rationale that underlies the current certification system. Due to time constraints, none of this material was presented. The material is included at the end of these notes. Algorithm Discussion There was extensive discussion of ways to use ``triple-DES'' on the pem-dev mailing list prior to this meeting. Mike Roe made a brief presentation on triple-DES options and distributed to attendees an extensive analysis he had prepared. There is agreement that use of EDE as a codebook is intrinsically slower than approaches that perform multiple chaining passes, if parallel hardware is employed. However, in the PEM (e-mail) context it is not clear that this performance improvement is a significant factor, especially if software DES (not executed in parallel on multiple processors) is the dominant implementation mode. In this context, the various triple-DES options are essentially equivalent in performance. It was suggested that the primary motivation for using triple-DES is security, not performance. Although there is significant literature supporting the security of EDE as a codebook, there is little if any analysis of the security of the other proposed modes. It was announced that RSA Labs will perform a study of the security of the different proposed modes and make a report available to the PEM Working Group. No resolution of this issue was reached at this meeting. Attendees Harald Alvestrand Harald.Alvestrand@uninett.no Frederik Andersen fha@dde.dk James Conklin jbc@bitnic.educom.edu Stephen Crocker crocker@tis.com Maria Dimou-Zacharova dimou@dxcern.cern.ch Kishan Dudkikar kishan@icm1.icp.net Steve Dusse spock@rsa.com Barbara Fraser byf@cert.org James Galvin galvin@tis.com Tim Goodwin tim@pipex.net Richard Graveman rfg@ctt.bellcore.com Neil Haller nmh@thumper.bellcore.com Alton Hoover hoover@ans.net Nada Kapidzic nadak@dsv.su.se Stephen Kent kent@bbn.com Peter Kirstein P.Kirstein@cs.ucl.ac.uk Jim Knowles jknowles@binky.arc.nasa.gov Arjen Lenstra lenstra@bellcore.com John Linn linn@gza.com Kim Chr. Madsen kimcm@ic.dk Keith Moore moore@cs.utk.edu Michael Roe mrr@cl.cam.ac.uk Jeffrey Schiller jis@mit.edu Wolfgang Schneider schneiw@darmstadt.gmd.de Robert Shirey shirey@mitre.org Theodore Ts'o tytso@mit.edu Lea Viljanen Lea.Viljanen@helsinki.fi Erik Zegwaart zegwaart@surfnet.nl James Zmuda zmuda@mls.hac.com Appendix One Material presented for the "Certificate Name Discussion'': ``Features'' for Names Used in Certificates Feature Distinguished Domain Name Name globally unique YES YES distributed generation YES YES descriptive YES NO->SOMEWHAT naming infrastructure SPARSE EXTENSIVE storage infrastructure GROWING EXTENSIVE mailbox independent YES NO->SOMEWHAT easy to remember MAYBE MAYBE easy to deduce MAYBE MAYBE easy to type NO YES - From a message submission perspective, a good PEM implementation should accept DNS names, DNs, or local alia ses as input from user to select recipients. All three forms could be mapped locally to the name form used in certificates. Many users make extensive use of local aliases, in which case mapping to a DN or a DNS name is equally easy. If DNs are used, one can help avoid suppress by allowing the sender to review the certificate names (prior to submission) to avoid the ``I securely sent the message to the wrong recipient'' phenomenon. - Received e-mail will always contain DNS names, but the name in the certificate is what is authenticated. One can argue that if both names are the same this makes it easier for the user (or software) to check, and hence DNS names should be favored. However, because mail systems sometimes translate DNS names in headers, often there may not be a 1-1 correspondence between the DNS name that appears in an 822 header for different recipients and that seen by the originator. Also, if a sender wants to employ the same certificate to send/receive mail at various mailboxes, or for persona certificate users, there cannot always be a direct correspondence between the mailbox name and the name contained in a certificate. - Although DNs are longer and more awkward to type than DNS names, a good PEM implementation would require a u ser to enter the name of a recipient at most once, and maybe never. For example, consider receipt of a certificate in a PEM message from a user with whom the recipient has not previously corresponded. A good PEM implementation can query the recipient for a (local) name to be assigned to the sender, thus avoiding any requirement for the recipient to type the certificate name associated with this sender. This local name could be an alias or could be the DNS name, at the discretion of the recipient. - If name subordination is to be maintained as a requirement for certificate validation below the PCA tier, th en this may be more easily done using DNs than DNS names, although this depends on details of organizational structure and DNS domain organization. - Some have complained that using a DN vs. a DNS name somehow usurps a user's ability to be represented by hi s existing DNS name. But messages continue to carry the same DNS names for originator and recipients as before. Also, many messages carry a commented ``more descriptive individual name'' adjacent to the originator's DNS name in the message header and some carry elaborate trailers providing organizational affiliation. Thus, some significant percentage of e-mail users already seem to feel that DNS names are not sufficiently descriptive. - It has been suggested that if DNs appear in certificates then the certificates must be stored in X.500 dire ctories. This is not correct. Certificates containing DNs (or DNS names) might be stored in various databases, e.g., whois++ or DNS servers, not only in X.500 directories. Certificates can be compressed to save space and/or encoded to permit storage in ASCII- only databases. Certificates can be retrieved based on any search key convenient for users. The fundamental requirement is that the name contained in the certificate be sufficiently descriptive so that the user can verify that the certificate retrieved corresponds to the entity in question, irrespective of the search key used. Appendix Two Material prepared for the ``Certification System Discussion'': PEM Certification Infrastructure ``Features'' - support for diverse policies In the global Internet environment, certificates will be issued under a number of different policies. The policies will differ based on the rigor with which organizational or individual identities are verified, CRLs are maintained, CA keys are generated and protected, etc. The certification infrastructure must accommodate this diversity, ranging from high assurance policies suitable for use in business and official government contexts, to persona policies. The current architecture achieves this through the use of Policy CAs (PCAs). - alerting users to trust policies Users must be made aware of the differences in trust policies, so that they can make informed decisions as to the trustworthiness of the identity information contained in a certificate. It must be possible for any user to determine (unambiguously) the policy under which any certificate was issued. The means by which a user is alerted to these differences should be simple, uniform, and automated. The current architecture achieves this through the use of PCAs, prohibition of cross-certification, and the requirement that PCA policies be available on-line. - ``what you see if what you believe'' principle We expect a recipient of a message to pay only minimal attention to the authentication information presented by PEM. At a minimum the name from the originator's certificate, or a local alias assigned to this name, should be displayed. The current architecture fulfills this requirement through display of the originator's distinguished name (or a local alias thereof). For an originator not already known to the recipient, this display not only uniquely identifies the originator, but also identifies superior CAs (because of the DN name subordination rule). Since different policies are supported, some form of identification of the policy under which this certificate was issued must be displayed. In the current architecture, this is effected by displaying the PCA's DN, or a local alias thereof. The combination of these two identifying data items provides a recipient with a fairly complete picture of the originator's identity. - minimizing trust in CAs In any distributed certification system, there is a valid concern about the extent of damage that can result from malicious or careless certification practices by a certifying authority. The signing of a certificate provides a basis for non-repudiable evidence of the (certification) actions of any certification authority. However, additional ``rules of conduct'' are required to establish generic expectations for certification authority behavior, especially in an architecture that admits a variety of certification policies. In the current architecture, the IPRA operates under a very straightforward policy in its certification of PCAs. The IPRA uses highly secure technology to generate and protect the private key it uses to sign PCA certificates, and employs stringent security procedures to protect the signing process. In the current architecture, PCAs are allowed greater leeway in defining the protection they afford to the keys used to sign CA certificates, and other security policy issues, but the PCAs are required to publish these procedures so that users can personally evaluate the quality of security afforded by PCAs and the CAs they certify. The IPRA requires PCAs to co-operate to ensure the uniqueness of the (distinguished) names of the entities they certify. This establishes a clear PCA responsibility and egregious failure to abide by this requirement constitutes cause for de-certifying a PCA. Each CA is required to issue certificates only for entities that are (distinguished) name subordinated to the CA. This requirement prevents a CA from issuing a certificate to a user (or a CA) that is not related to the CA in an obvious, syntactic fashion. This restricts the damage that a careless or malicious CA can do, by limiting the scope of certification of each CA. - uniform certification processing rules Although certification policies differ, it is important to employ a uniform algorithm for validating certificates. This algorithm should be simple, both to minimize the likelihood of implementation errors and to make the validation process understandable by users. In the current architecture, the validation rules are consistent across PCA boundaries and for all CAs, despite policy differences. This certification system is simple, with explicit recognition of IPRA, PCA and CA tiers. The IPRA public key is the root of the certification system and thus is ``built into'' an implementation. A PCA, CA, or user certificate is validated relative to its issuer's public key in all cases. A user certificate, or a certificate for a CA subordinate to another CA (vs. a PCA), must also be checked for subordination relative to it's issuer.