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

                                  2





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



                                  3

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.