Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/pem/pem-minutes-92nov.txt

Text File | 1993-02-17 | 7KB | 155 lines

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           [e-mail]
Fred Bohle               [e-mail]
David Conklin            [e-mail]
James Conklin            [e-mail]
Chuck Cranor             [e-mail]
Stephen Crocker          [e-mail]

                                   2





Art Dertke               [e-mail]
Steve Dusse              [e-mail]
William Edison
Barbara Fraser           [e-mail]
Shari Galitzer           [e-mail]
James Galvin             [e-mail]
Richard Graveman         [e-mail]
Terry Gray               [e-mail]
Neil Haller              [e-mail]
Alton Hoover             [e-mail]
Christian Huitema        [e-mail]
Phil Karn                [e-mail]
Stephen Kent             [e-mail]
John Linn                [e-mail]
Steven Lunt              [e-mail]
Louis Mamakos            [e-mail]
Mohammad Mirhakkak       [e-mail]
Clifford Neuman          [e-mail]
Hilarie Orman            [e-mail]
Joseph Ramus             [e-mail]
Alan Roszkiewicz         [e-mail]
Paul Sangster            [e-mail]
Sam Schaen               [e-mail]
Jeffrey Schiller         [e-mail]
Robert Shirey            [e-mail]
Tang Tang                [e-mail]
Theodore Ts'o            [e-mail]
Gregory Vaudreuil        [e-mail]
Chuck Warlick            [e-mail]
Moira West               [e-mail]
Daniel Woycke            [e-mail]
Peter Yee                [e-mail]



                                   3