Editor's Note: 11/19/92 CURRENT_MEETING_REPORT_ Reported by Steve Kent/BBN Minutes of the Privacy-Enhanced Mail Working Group (PEM) A review of document status was provided by Steve Crocker, the Security Area Director. Three of the four documents are ready for progression, and the fourth (RFC 1115bis) needs to be edited to make it clear that additional algorithm suites will be published via new RFCs, but this is viewed as a minor edit and thus should not hold up progression of the documents. Steve indicated that the documents will be recommended for progression very soon, perhaps at the Friday IESG meeting. RFC 1115bis also needs to be revised to remove use of DES MAC as a message integrity code. Recent work has indicated that use of DES MAC is unsuitable with either symmetric or asymmetric key management algorithms, even in the limited contexts already defined in 1115bis. Only one party who might object to this removal of DES MAC was identified and he will be promptly notified of the planned change. here too, the change is considered minor as it involves removal of what is viewed as an option which was not expected to see much, if any, use. The Working Group received a hardcopy handout of an Internet-Draft written by Steve Crocker, Ned Freed, and Marshall Rose. The Internet-Draft proposes an approach to integrating MIME and PEM. Ned Freed presented this approach to the Working Group and discussion ensued: o There was agreement that the current processing description for submission should not be proscriptive, i.e., alternative user interface options for invoking PEM for a MIME message are permitted. Thus section 5.1 needs to be revised to avoid any implications that the pre-submission processing is a description of a user interface requirement. The goal here is to convey what needs to be done, but not to imply a required user interface form. o It was suggested that additional formats could be defined in MIME to transport certificates, exclusive of their transport in the PEM header. This is not in conflict with the current proposal, but was generally regarded as a very useful addition. o There was a discussion of what 5.1.2 in the Internet-Draft implies. The intent was that step would transform any input into MIME canonical form. Discussion explored the use of the new (as of last IETF meeting) PEM header field ``Content-Domain'' to represent the canonicalization performed by PEM. This field was intended to allow other than vanilla 822 canonicalization to be performed on the input to PEM, in an effort to avoid redundant encoding steps. o It was suggested that the PEM MIC-ONLY option is not required in the MIME environment as MIME will employ a transfer encoding that 1 preserves the PEM message. Thus MIC-CLEAR could be used in lieu of MIC-ONLY, avoiding a redundant encoding step. However, MIC-CLEAR does pose real danger when ``helpful'' mail relays are involved, i.e., if MIME is not available at all recipients, even if some recipients do have (non-MIME) PEM. It also is suggested that inclusion of a redundant, cleartext body part is a means of accommodating the recipients for whom MIC-CLEAR was developed. Thus this issue is unresolved. o It is not clear that the canonical encoding options now used in MIME preserve the reversibility required for signature preservation in forwarded messages. This is a cause for some concern and requires further examination. o There was debate over whether the preferred approach here is to define a new PEM Content-Domain for use with MIME, allowing any (8-bit) input and avoiding possibly redundant base64 encoding, or to use only the existing PEM 822 Content-Domain and impose the base64 encoding in all cases. o The question was raised as to whether the PEM header needs to indicate Content-Domain MIME when the PEM header is already within a MIME message, or is it redundant? the issue was not resolved and requires further study. o It is suggested by several attendees that the Content-Annotation proposed in section 6, needs to be dropped or improved. It does not provide enough information to preserve all of the security information that PEM provides. There is considerable feeling that there is a difference between what is displayed to the user as part of message reading, vs. what is retained when the message is stored. The message may be stored in enciphered form, in signed only form, or without any cryptographic (PEM) protection. It was argued that the labeling of a stored message which was previously protected by PEM is strictly a local matter and thus should not be part of the MIME header (nor part of the MIME-PEM specification). o There was agreement to continue this discussion on the PEM-DEV mailing list and at the next IETF meeting. The authors of the Internet-Draft, which was the focal point of this discussion, agreed to work on a successor version, taking into account the various issues raised and discussed during this meeting. The PEM and MIME Working Group Chairs agreed to request that future PEM and MIME Working Group meetings during IETF be explicitly scheduled to not conflict with one another. Attendees David Balenson balenson@tis.com Fred Bohle fab@interlink.com David Conklin conklin@jvnc.net James Conklin jbc@bitnic.educom.edu Chuck Cranor chuck@maria.wustl.edu Stephen Crocker crocker@tis.com 2 Art Dertke dertke@gateway.mitre.org Steve Dusse spock@rsa.com William Edison Barbara Fraser byf@cert.org Shari Galitzer shari@mitre.org James Galvin galvin@tis.com Richard Graveman rfg@ctt.bellcore.com Terry Gray gray@cac.washington.edu Neil Haller nmh@thumper.bellcore.com Alton Hoover hoover@ans.net Christian Huitema christian.huitema@sophia.inria.fr Phil Karn karn@qualcomm.com Stephen Kent kent@bbn.com John Linn linn@erlang.enet.dec.com Steven Lunt lunt@bellcore.com Louis Mamakos louie@ni.umd.edu Mohammad Mirhakkak mmirhakk@mitre.org Clifford Neuman bcn@isi.edu Hilarie Orman ho@cs.arizona.edu Joseph Ramus ramus@nersc.gov Alan Roszkiewicz alan@sprint.com Paul Sangster sangster@ans.net Sam Schaen schaen@mitre.org Jeffrey Schiller jis@mit.edu Robert Shirey shirey@mitre.org Tang Tang tt@virginia.edu Theodore Ts'o tytso@mit.edu Gregory Vaudreuil gvaudre@cnri.reston.va.us Chuck Warlick warlick@theophilis.nsfc.nasa.gov Moira West mjw@cert.org Daniel Woycke woycke@smiley.mitre.org Peter Yee yee@atlas.arc.nasa.gov 3