CURRENT_MEETING_REPORT_ Reported by Steve Kent/BBN Minutes of the Privacy Enhanced Mail Working Group (PEM) A show of hands indicated that about 70-75% of the attendees were new (i.e., have not previously attended a PEM Working Group meeting). A number of 822EXT Working Group members attended, probably because of the first agenda topic. MIME/PEM Integration The primary agenda topic for this meeting was a review of the latest MIME/PEM Internet-Draft, published about two weeks prior to this meeting. Steve Crocker lead the discussion of this new draft, explaining the major features of this proposal, in particular, noting differences between this proposal and the features provided by the PEM format defined by RFC 1421. These features include: o Optional use of separate keys for encryption and signature; o Protection of any content type, through recursive use of the MIME multipart construct; o Use of MIME transfer encoding (e.g., ``quoted-printable'') to eliminate the need for the MIC-CLEAR processing type; o Encryption and signature control information separate from the message body; o Encryption and signature control information placed at the end of the message; o CRLs, certificates, etc., all supported in a message via separate body parts, removing the need for separate message types for management functions (e.g, CRL distribution and requests, etc.); and o Optional inclusion of message header information within protected boundary (e.g., if message/RFC822 is the encapsulated body part type). Some of these features precipitated some discussion. For example, it was noted that placing encryption (versus signature) control information at the end of the message precludes one-pass message processing. The primary motivation for placing encryption and signature control information at the end of the message is to reduce visual clutter, especially for non-PEM recipients. However, this rationale does not apply to encrypted messages (which, by definition, are not directed to non-PEM users), so there appears to be much less motivation to place encryption data at the end of a message. The discussion suggested that review of this aspect of the design is in order. The only significant problem uncovered during the review relates to forwarding of signed messages, especially ones that contain other than just text. The problem here is that the proposal relies on use of MIME context transfer encoding (CTE) to produce a canonical representation for content. Canonicalization is critical for the transmission of signed data, to ensure that a recipient can verify the signature. However, the CTE is only pair-wise between an originator and the ``original'' set of recipients for a message. If one of these recipients forwards a signed message to a third party, a different CTE may be employed, resulting in a different representation for the content, and a consequent failure of the signature on the forwarded message. This discussion suggested that the proposal be modified so that an originator can specify a fixed, canonical encoding for a content, enabling forwarding of signed messages that preserves the original encoding. The authors of this MIME/PEM proposal agreed to go back and work on this last problem, producing a new proposal that addresses this rather critical problem. One last issue was briefly discussed under this agenda topic, but a decision was deferred. The issue is whether a MIME/PEM RFC should supersede RFC 1421, or whether we should have parallel MIME and ``vanilla'' RFC 822 versions of PEM. There was some sentiment expressed for maintaining these as parallel RFCs, but the decision has been deferred pending availability of a MIME/PEM RFC. Changes in Working Group Organization In consultation with the outgoing and incoming Security Area Directors, it has been decided to reorganize the PEM Working Group, as described below. The PEM Working Group will soon be redefined to encompass a limited scope, namely the syntax and top-level processing of PEM messages. One or more new working groups will soon be created to address the topic of certification management. One of these working groups will address design of a certification system that is not hierarchical (in contrast to the one defined in RFC 1422), and a second working group may be created to continue to refine the sort of hierarchical certification system currently described in RFC 1422. Discussion of Certification System Parameters The remainder of the working group session was devoted to a brief review of various characteristics of certification systems that have been the focus of recent debate on the mailing list (e.g., the form of names in certificates, self-signed certificates, etc.). Since this discussion was just a brief, top-level review of the more detailed discussions that have taken place on the mailing list, no detailed minutes are provided on this portion of the meeting. Attendees Perkins Bass bass@eskimo.com John Beck jbeck@cup.hp.com Kym Blair kdblair@dockmaster.ncsc.mil Steven Blair sblair@dell.com Larry Blunk ljb@merit.edu David Carrel carrel@cisco.com Rong Chang rong@watson.ibm.com Wallace Colyer wally+@cmu.edu Jim Conklin jbc@bitnic.educom.edu Naomi Courter naomi@concert.net Shane Davis shane@delphi.com Peter DiCamillo Peter_DiCamillo@brown.edu Cheri Dowell cdowell@atlas.arc.nasa.gov Donald Eastlake dee@lkg.dec.com Erik Fair fair@apple.com Antonio Fernandez afa@bellcore.com Lois Frampton frampton@mitre.org Barbara Fraser byf@cert.org Jerome Freedman jfjr@mbunix.mitre.org James Galvin galvin@tis.com Chris Gorsuch chrisg@lobby.ti.com Richard Graveman rfg@ctt.bellcore.com Terry Gray gray@cac.washington.edu Dragan Grebovich dragan@bnr.ca Richard Harris rharris@atc.boeing.com Marco Hernandez marco@cren.net Marc Horowitz marc@security.ov.com Ryu Inada ryu@fujixerox.co.jp Robert Karsten robert@lachman.com Charlie Kaufman kaufman@zk3.dec.com Stephen Kent kent@bbn.com Paul Lambert paul_lambert@email.mot.com Lars-Johan Liman liman@sunet.se John Linn linn@security.ov.com Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Michael Michnikov mbmg@mitre.org Paul Mockapetris pvm@isi.edu Kim Morla kmorla@pucp.edu.pe Sandra Murphy murphy@tis.com John Myers jgm+@cmu.edu Chris Newman chrisn+@cmu.edu Radia Perlman perlman@novell.com Michael Ressler mpr@ctt.bellcore.com Corey Satten corey@cac.washington.edu Chris Seabrook cds@ossi.com Michael St. Johns stjohns@arpa.mil Einar Stefferud stef@nma.com Don Stephenson don.stephenson@sun.com Jeff Thompson jefft@rsa.com Theodore Ts'o tytso@mit.edu Gregory Vaudreuil g.vaudreuil@octel.com Dale Walters walters@osi3.ncsl.nist.gov John Wray wray@tuxedo.enet.dec.com Suguru Yamaguchi yamaguti@wide.ad.jp Shinichi Yoshida yoshida@sumitomo.com