CURRENT_MEETING_REPORT_ Reported by Steve Kent/BBN Minutes of the Privacy Enhanced Mail Working Group (PEM) A quick poll of attendees indicated about 60-70% are new, i.e., have not previously attended a PEM Working Group meeting. A number of MIME Working Group members attended because of the MIME-PEM topic. Implementation Status Reports MIT: Jeff Schiller reported that the status was mostly unchanged from Amsterdam; anonymous FTP availability at MIT for a Mac implementation, integrated with TechMail messaging software (uses POP3 server); expected new release in a few weeks, with bug fixes and some new user interface features; an X-windows version will become available later. TIS: Jim Galvin reported that version 6.1 was released on October 29; available via anonymous FTP from TIS for United States and Canadian users; an RFC 1421 implementation. A United Kingdom-developed version is under way at the TIS United Kingdom office, targeted for PCs. No other PEM implementation representatives were present. Electronic Notary Services Dave Solo provided a presentation on various ``notary-style'' validation services for non-repudiation (see slides following the minutes): o Simple time stamping o Enhanced non-repudiation o Document registration o Archival signature validation o Assurance issues o Validation of other attributes The group observed that non-repudiation with proof of submission and/or delivery are not viable services in much of the Internet because the submission and delivery agents are usually under the administrative control of the originator and recipient (or their respective organizations). Only if one has a timestamp notary which acts as a mail forwarder does one recapture the proof of submission notion, but that makes the notary an element of the MHS, and requires double enveloping by the originator (to direct the original message to the notary/forwarder). MIME-PEM (The Saga Continues) About 50% of attendees have read the Internet-Drafts issued on this topic last week. o MIME-PEM ``lite'' (Jeff Schiller) This design requires very minimal changes to existing PEM and is capable of accommodating simple MIME-PEM constructs. It utilizes the Content-Domain construct to identify the payload of the message as requiring this enhanced form of processing. The goal is to add MIME capability to existing PEM implementations without substantial delay. INRIA and Bellcore report that they have implemented this design and found it quite simple. Some attendees note that most Macintosh clients don't have MIME and this approach minimizes the effort required for a (simple) PEM- MIME system. There was a suggestion to modify the current proposal to employ an ``application/text'' content type for MIC- CLEAR messages and use ``application/1421'' for MIC-ONLY and ENCRYPTED. o MIME-PEM ``full-bodied'' (Steve Crocker) The goal is a design that preserves maximal functionality for PEM and MIME users, all MIME content types, etc. There is no backward compatibility goal. It does away with MIC-CLEAR and MIC-ONLY distinction, because MIME content transfer encoding addresses that requirement. It separates PEM header information from the message body. One major change from the previous design is use of ``application/quoted-mime-entity'' to make the PEM body opaque, protecting the body against MIME gateway transformations. Another change is the separation of certificate and CRLs into a separate body part. The constructs for encryption and signature are capable of being nested in either order, for forwarding signed, encrypted messages. Constructs allow for sending certificate chains and/or CRL chains plus use of the same facility for CRL and certificate queries. [Working group Chair observations after the meeting: The thrust of the first proposal is preservation of the investment in current PEM implementations designed to operate with (vanilla) 822 messages, while extending these implementations to support MIME constructs in the simplest possible fashion. This proposal also addresses the processing of PEM-MIME messages by MIME mail readers that do not provide integrated support for PEM and by PEM implementations that do not provide integrated MIME support. The proposal is extremely simple to implement and is backwards compatible with the current PEM design, e.g., it makes use of the Content-Domain header construct to identify a MIME content. The second proposal represents a fairly radical departure from RFC 1421, essentially re-engineering PEM for the MIME environment, in order to provide more flexible security services for (extensible) MIME UAs. As a result, this design is not backward compatible with current 1421 implementations. The path being pursued here, through these two proposals, does not converge in a single PEM implementation serving both basic 822 and MIME UAs. This is an unfortunate outcome, but it is the result of a long period of work by a number of individuals in both the PEM and MIME working groups. When MIME replaces basic 822 as the ubiquitous e-mail protocol throughout the Internet and the other networks that are e-mail-connected to the Internet, then the second proposal probably becomes the obvious choice, due to its increased functionality. However, prior to that time, the group will pursue dual approaches that accommodate distinct subscriber groups within the MIME-PEM user community.] A Certificate Server Proposal for PEM This proposal, presented by Christian Huitema, is designed to facilitate retrieval of certificates and CRLs with locally managed, simple databases. Index for search is the user's mailbox name. This calls for operators of the hosts that provide the user's mailbox to provide this responder facility. However, mail services such as CompuServ and MCIMail are unlikely to provide this service. There may be a need to create a new record type to allow indirection to other than the user's actual mailbox provider. Also, this proposal is based on TCP, but not all prospective PEM users are reachable by TCP, e.g., users of non-IP nets or firewall. A suggestion was made to add this facility to FINGER instead, to minimize firewall problems? Suggest e-mail-based access should be baseline, with real-time access an optional additional service. Triple DES Burt Kalaski was not available to lead discussion at this meeting so the topic was defered. This is still an important topic but the group is awaiting publication (later this year) of an analysis which is purported to reach conclusions at odds with those of the analysis prepared by Burt. In the mean time, all interested parties are encouraged to read the analysis posted to the PEM-DEV list during the last week of October. Attendees Garrett Alexander gda@tycho.ncsc.mil Alireza Bahreman bahreman@bellcore.com Stephen Crocker crocker@tis.com Donald Eastlake dee@skidrow.lkg.dec.com Erik Fair fair@apple.com Qin Fang qin_fang@unc.edu Antonio Fernandez afa@thumper.bellcore.com James Fielding jamesf@arl.army.mil James Galvin galvin@tis.com Jisoo Geiter geiter@mitre.org Chris Gorsuch chrisg@lobby.ti.com Terry Gray gray@cac.washington.edu Christian Huitema Christian.Huitema@sophia.inria.fr Neil Katin katin@eng.sun.com Charlie Kaufman kaufman@zk3.dec.com Stephen Kent kent@bbn.com Paul Lambert paul_lambert@email.mot.com John Linn linn@security.ov.com Steven Lunt lunt@bellcore.com Chip Matthes chip@delphi.com Wayne McDilda wayne@dir.texas.gov Michael Michnikov mbmg@mitre.org Keith Moore moore@cs.utk.edu Sandra Murphy murphy@tis.com John Myers jgm+@cmu.edu Chris Newman chrisn+@cmu.edu Karen Petraska-Veum karen.veum@gsfc.nasa.gov Jeffrey Schiller jis@mit.edu Wolfgang Schneider schneiw@darmstadt.gmd.de Dave Solo solo@bbn.com Theodore Ts'o tytso@mit.edu Gregory Vaudreuil gvaudre@cnri.reston.va.us David Woodgate David.Woodgate@its.csiro.au Peter Yee yee@atlas.arc.nasa.gov