PEM WG Meeting Minutes 11/3/93
A quick poll of attendees indicates about 60-70% are new, i.e.,
have not previously attended a PEM WG meeting. A number of MIME
WG members attended because of agenda item #3.
1. Implementation Status Reports:
- MIT: (Jeff Schiller-MIT) status 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-TIS) version 6.1 release on 10/29;
available via anonymous FTP from TIS for US and Canadian users;
an RFC 1421 implementation. a UK-developed version is under way
at the TIS UK office, targeted for PCs.
- No other PEM implementation representatives were present.
2. Electronic Notary Services (Dave Solo-BBN)
Dave provided a presentation on various "notary-style" validation
services for non-repudiation (see slides in IETF proceedings):
- simple time stamping
- enhanced non-repudiation
- document registration
- archival signature validation
- assurance issues
- validation of other attributes
We observe 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
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).
3. MIME-PEM (the saga continues)
About 50% of attendees have read the I-Ds issued on this topic
last week.
- MIME-PEM "lite" (Jeff Schiller-MIT)
This design requires very minimal changes to existing PEM and is
capable of accommodating simple MIME-PEM constructs. Utilizes
the Content-Domain construct to identify the payload of the
message as requiring this enhanced form of processing. 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.
- MIME-PEM "full-bodied" (Steve Crocker-TIS)
Goal is a design that preserves maximal functionality for PEM and
MIME users, all MIME content types, etc. There is no backward
compatibility goal. Does away with MIC-CLEAR and MIC-ONLY
distinction, because MIME content transfer encoding addresses
that requirement. 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.
[WG Chair observations aftr 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 WGs. When MIME replaces basic 822 as the
ubiquitous email protocol throughout the Internet and the other
networks that are email-connected to the Internet, then the
second proposal probably becomes the obvious choice, due to its
increased functionality. However, prior to that time, we will
pursue dual approaches that accommodate distinct subscriber
groups within the MIME-PEM user community.]
4. A certificate server proposal for PEM (Christian Huitema-
INRIA)
A proposal 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. May 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. Suggestion to add this facility to
FINGER instead, to minimize firewall problems? Suggest email-
based access should be baseline, with real-time access an
optional additional service.
5. Triple DES (deferred, Burt Kalaski not available to lead
discussion at this meeting)
This is still an important topic but we are 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 by Burt during the last
week of October.