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

Text File | 1994-02-23 | 8KB | 186 lines

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        [e-mail]
Alireza Bahreman         [e-mail]
Stephen Crocker          [e-mail]
Donald Eastlake          [e-mail]
Erik Fair                [e-mail]
Qin Fang                 [e-mail]
Antonio Fernandez        [e-mail]
James Fielding           [e-mail]
James Galvin             [e-mail]
Jisoo Geiter             [e-mail]
Chris Gorsuch            [e-mail]
Terry Gray               [e-mail]
Christian Huitema        [e-mail]
Neil Katin               [e-mail]
Charlie Kaufman          [e-mail]
Stephen Kent             [e-mail]
Paul Lambert             [e-mail]
John Linn                [e-mail]
Steven Lunt              [e-mail]
Chip Matthes             [e-mail]
Wayne McDilda            [e-mail]
Michael Michnikov        [e-mail]
Keith Moore              [e-mail]
Sandra Murphy            [e-mail]
John Myers               [e-mail]
Chris Newman             [e-mail]
Karen Petraska-Veum      [e-mail]
Jeffrey Schiller         [e-mail]
Wolfgang Schneider       [e-mail]
Dave Solo                [e-mail]
Theodore Ts'o            [e-mail]
Gregory Vaudreuil        [e-mail]
David Woodgate           [e-mail]
Peter Yee                [e-mail]