CURRENT_MEETING_REPORT_
Reported by Steve Kent/BBN
Minutes of the Privacy Enhanced Mail Working Group (PEM)
A show of hands indicated that about 70-75% of the attendees were new
(i.e., have not previously attended a PEM Working Group meeting). A
number of 822EXT Working Group members attended, probably because of the
first agenda topic.
MIME/PEM Integration
The primary agenda topic for this meeting was a review of the latest
MIME/PEM Internet-Draft, published about two weeks prior to this
meeting. Steve Crocker lead the discussion of this new draft,
explaining the major features of this proposal, in particular, noting
differences between this proposal and the features provided by the PEM
format defined by RFC 1421.
These features include:
o Optional use of separate keys for encryption and signature;
o Protection of any content type, through recursive use of the MIME
multipart construct;
o Use of MIME transfer encoding (e.g., ``quoted-printable'') to
eliminate the need for the MIC-CLEAR processing type;
o Encryption and signature control information separate from the
message body;
o Encryption and signature control information placed at the end of
the message;
o CRLs, certificates, etc., all supported in a message via separate
body parts, removing the need for separate message types for
management functions (e.g, CRL distribution and requests, etc.);
and
o Optional inclusion of message header information within protected
boundary (e.g., if message/RFC822 is the encapsulated body part
type).
Some of these features precipitated some discussion. For example, it
was noted that placing encryption (versus signature) control information
at the end of the message precludes one-pass message processing. The
primary motivation for placing encryption and signature control
information at the end of the message is to reduce visual clutter,
especially for non-PEM recipients. However, this rationale does not
apply to encrypted messages (which, by definition, are not directed to
non-PEM users), so there appears to be much less motivation to place
encryption data at the end of a message. The discussion suggested that
review of this aspect of the design is in order.
The only significant problem uncovered during the review relates to
forwarding of signed messages, especially ones that contain other than
just text. The problem here is that the proposal relies on use of MIME
context transfer encoding (CTE) to produce a canonical representation
for content. Canonicalization is critical for the transmission of
signed data, to ensure that a recipient can verify the signature.
However, the CTE is only pair-wise between an originator and the
``original'' set of recipients for a message. If one of these
recipients forwards a signed message to a third party, a different CTE
may be employed, resulting in a different representation for the
content, and a consequent failure of the signature on the forwarded
message. This discussion suggested that the proposal be modified so
that an originator can specify a fixed, canonical encoding for a
content, enabling forwarding of signed messages that preserves the
original encoding.
The authors of this MIME/PEM proposal agreed to go back and work on this
last problem, producing a new proposal that addresses this rather
critical problem.
One last issue was briefly discussed under this agenda topic, but a
decision was deferred. The issue is whether a MIME/PEM RFC should
supersede RFC 1421, or whether we should have parallel MIME and
``vanilla'' RFC 822 versions of PEM. There was some sentiment expressed
for maintaining these as parallel RFCs, but the decision has been
deferred pending availability of a MIME/PEM RFC.
Changes in Working Group Organization
In consultation with the outgoing and incoming Security Area Directors,
it has been decided to reorganize the PEM Working Group, as described
below.
The PEM Working Group will soon be redefined to encompass a limited
scope, namely the syntax and top-level processing of PEM messages. One
or more new working groups will soon be created to address the topic of
certification management. One of these working groups will address
design of a certification system that is not hierarchical (in contrast
to the one defined in RFC 1422), and a second working group may be
created to continue to refine the sort of hierarchical certification
system currently described in RFC 1422.
Discussion of Certification System Parameters
The remainder of the working group session was devoted to a brief review
of various characteristics of certification systems that have been the
focus of recent debate on the mailing list (e.g., the form of names in
certificates, self-signed certificates, etc.). Since this discussion
was just a brief, top-level review of the more detailed discussions that
have taken place on the mailing list, no detailed minutes are provided
on this portion of the meeting.
Attendees
Perkins Bass bass@eskimo.com
John Beck jbeck@cup.hp.com
Kym Blair kdblair@dockmaster.ncsc.mil
Steven Blair sblair@dell.com
Larry Blunk ljb@merit.edu
David Carrel carrel@cisco.com
Rong Chang rong@watson.ibm.com
Wallace Colyer wally+@cmu.edu
Jim Conklin jbc@bitnic.educom.edu
Naomi Courter naomi@concert.net
Shane Davis shane@delphi.com
Peter DiCamillo Peter_DiCamillo@brown.edu
Cheri Dowell cdowell@atlas.arc.nasa.gov
Donald Eastlake dee@lkg.dec.com
Erik Fair fair@apple.com
Antonio Fernandez afa@bellcore.com
Lois Frampton frampton@mitre.org
Barbara Fraser byf@cert.org
Jerome Freedman jfjr@mbunix.mitre.org
James Galvin galvin@tis.com
Chris Gorsuch chrisg@lobby.ti.com
Richard Graveman rfg@ctt.bellcore.com
Terry Gray gray@cac.washington.edu
Dragan Grebovich dragan@bnr.ca
Richard Harris rharris@atc.boeing.com
Marco Hernandez marco@cren.net
Marc Horowitz marc@security.ov.com
Ryu Inada ryu@fujixerox.co.jp
Robert Karsten robert@lachman.com
Charlie Kaufman kaufman@zk3.dec.com
Stephen Kent kent@bbn.com
Paul Lambert paul_lambert@email.mot.com
Lars-Johan Liman liman@sunet.se
John Linn linn@security.ov.com
Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk
Michael Michnikov mbmg@mitre.org
Paul Mockapetris pvm@isi.edu
Kim Morla kmorla@pucp.edu.pe
Sandra Murphy murphy@tis.com
John Myers jgm+@cmu.edu
Chris Newman chrisn+@cmu.edu
Radia Perlman perlman@novell.com
Michael Ressler mpr@ctt.bellcore.com
Corey Satten corey@cac.washington.edu
Chris Seabrook cds@ossi.com
Michael St. Johns stjohns@arpa.mil
Einar Stefferud stef@nma.com
Don Stephenson don.stephenson@sun.com
Jeff Thompson jefft@rsa.com
Theodore Ts'o tytso@mit.edu
Gregory Vaudreuil g.vaudreuil@octel.com
Dale Walters walters@osi3.ncsl.nist.gov
John Wray wray@tuxedo.enet.dec.com
Suguru Yamaguchi yamaguti@wide.ad.jp
Shinichi Yoshida yoshida@sumitomo.com