CURRENT_MEETING_REPORT_ Reported by Steve Kent/BBN Minutes of the Privacy Enhanced Mail Working Group (PEM) The PEM Working Group met at the 26th IETF, with approximately 45 attendees. The meeting began with a status update. It was noted that the PEM RFCs were published in February as Proposed Standards. The TISPEM implementation has been available for awhile and a revised version, with improved documentation and CRL support, will become available in April. Plans are underway to transition TISPEM from use of BSAFE to RSAREF for cryptographic algorithms and to make installation easier, especially for single- user systems. Plans for easier distribution of TISPEM, perhaps via anonymous FTP with suitable export control warnings, are also under review. PEM implementations will soon become available in the United Kingdom and Germany as a result of work under the EC PASSPORT program. Testing of these implementations is taking place with the TISPEM and other PEM implementations. An authentication-only (MIC-ONLY and MIC-CLEAR) version will be available from University College London (UCL) to facilitate international distribution. A full PEM (including encryption) implementation is expected to be available via anonymous FTP in Germany. RSADSI noted that an updated PEM toolkit will be available for testing this summer. RSADSI announced that a ``commercial assurance PCA,'' was suitable for use in a variety of high assurance environments. It was noted that users of Apple's OCE will be registered under this PCA. RSADIS also announced the creation of a ``low assurance'' PCA with two classes of CAs. One class is a for CAs suitable for support of testing, and these CAs can be registered at no cost now and at a minimal cost in the future. A Persona CA, operated as an automated responder, soon will be instantiated under this PCA, providing free certificates with unauthenticated names. Trusted Information Systems (TIS) announced that it was planning to operate a ``medium assurance'' PCA and had developed a draft policy statement. UCL observed that it was planning to become a PCA and wished to examine the PCA statements from TIS and RSADSI in order to get a better understanding of the form of such statements. In addition to providing its TISPEM status update, TIS introduced two discussion topics: use of mailbox names, (rather than distinguished names), in certificates and relaxing the certification hierarchy constraints. It was suggested that Domain Name System (DNS) names could be encoded in X.509 certificate format by creating a new attribute, the value of which would be a DNS mailbox name. An alternative suggestion was put forth to represent a mailbox name as a sequence of AVAs, each corresponding to one component of a DNS name (plus the user name). Several motivations for this proposal were provided, including: 1 o It permits a user to become a PEM user more easily as it does not require the user to determine his distinguished name o It allows a user to employ his existing mailbox name for authentication. It was observed that this naming proposal is not likely to scale as well as the use of true distinguished names nor does it provide users with authenticated, descriptive identifiers. It was suggested that the use of DNS names in certificates might facilitate storage of certificates in the DNS, but this claim was not substantiated. TIS also suggested that it would be appropriate to consider relaxing the current certification system. The motivations cited here included a desire to facilitate the deployment of PEM to users not connected to the Internet and to incorporate trust models not accommodated by the current certification system. No specific, detailed proposals were put forth, but TIS announced plans to make material available later. It was observed that if the current certification path validation rules are substantially relaxed, the result may be a system with functionality no better than systems such as PGP. PEM and MIME Integration The rest of the meeting was devoted to a discussion of the integration of PEM and MIME. The proposal put forth by the MIME Working Group Chair was to formally supersede RFC1421 with a specification for PEM which requires a minimal MIME implementation. The requirements for a minimally compliant MIME mailer, from both submission and delivery perspectives was presented. Changes required relative to existing PEM processing includes recognition of static MIME header fields, adding the quoted-printable transformation, generation and parsing of multipart and text content types, support of ISO 8859-n character sets, and support for parameterized boundary markers (not compatible with the current PEM boundary markers). There were some strong objections to this proposal, on several grounds. For example, the MIME-PEM specification is not yet complete and there are a number of details in the currently published MIME-PEM specification which are contentious (e.g., the use of inband markers for local control of PEM submission processing and delivery indication of applied PEM processing), so a gap of six or more months would result if deployment 822-PEM implementations were discouraged or halted until MIME-PEM is available. Also, this proposal would disenfranchise non-MIME users, which was viewed as an unacceptable result. Other attendees argued that they would not consider implementing 822- PEM and would wait for MIME-PEM because of a desire to support only MIME users. There was general agreement that it would be advantageous for users to migrate to MIME-PEM. There was little or no support for the concept of requiring gateways to translate between 822- PEM and MIME-PEM users. Thus an outstanding question is whether there is any way to provide 2 interoperability between 822-PEM and MIME-PEM users with minimal changes to 822-PEM and/or minimal extensions to MIME-PEM. A related question is the extent to which MIME-PEM can be profiled for 822 users, to minimize the burden for such users. The Working Group agreed that revision of the MIME-PEM specification should be aggressively pursued with the intent that the revised specification should be thoroughly reviewed prior to the next IETF meeting in Amsterdam, when the PEM Working Group will meet. In parallel, an examination of options for 822-PEM and MIME-PEM interoperability, e.g., minor 822-PEM revisions and suitable profiling of MIME-PEM for use with text-only messages, will be undertaken. Attendees Harald Alvestrand Harald.Alvestrand@delab.sintef.no Jules Aronson aronson@nlm.nih.gov Richard Bjers rich.bjers@uc.edu Nathaniel Borenstein nsb@bellcore.com Sandy Bryant slb@virginia.edu John Campbell jrcamp@nosc.mil William Chung whchung@watson.ibm.com Steve Dusse spock@rsa.com Antonio Fernandez afa@thumper.bellcore.com Michael Fidler fidler@mitre.org Barbara Fraser byf@cert.org Ned Freed ned@innosoft.com Raphael Freiwirth 5242391@mcimail.com James Galvin galvin@tis.com Christine Garland garland@ihspa.att.com Jisoo Geiter geiter@mitre.org Terry Gray gray@cac.washington.edu Richard Harris rharris@atc.boeing.com Gerd Holzhauer holzhauer1@applelink.apple.com Alton Hoover hoover@ans.net Christian Huitema christian.huitema@sophia.inria.fr David Katinsky dmk@pilot.njin.net Charles Kaufman kaufman@zk3.dec.com Stephen Kent kent@bbn.com Peter Kirstein P.Kirstein@cs.ucl.ac.uk Jim Knowles jknowles@binky.arc.nasa.gov John Linn linn@gza.com Kent Malave kent@bach.austin.ibm.com Bob Morgan morgan@networking.stanford.edu Noel Nazario nazario@sdns.ncsl.nist.gov Emmanuel Pasetes ekp@enlil.premenos.sf.ca.us Bradley Rhoades bdrhoades@mail.mmmg.com April Richstein amr@tycho.ncsc.mil Gary Rowe gjrowe@attmail.com Jeffrey Schiller jis@mit.edu Wolfgang Schneider schneider@gmd.de Einar Stefferud stef@nma.com Stuart Stubblebine stubblebine@isi.edu 3 Louisa Thomson louisa@whitney.hac.com Klaus Truoel truoel@gmd.de Theodore Ts'o tytso@mit.edu Gregory Vaudreuil gvaudre@cnri.reston.va.us Chuck Warlick warlick@theophilis.nsfc.nasa.gov James Weatherford weatherf@nosc.mil 4