InfoMagic Standards 1993 July/Disc.iso/inet/ietf/pem/93mar.min

Text File | 1993-05-13 | 8.5 KB | 192 lines

CURRENT_MEETING_REPORT_


Reported by Steve Kent/BBN

Minutes of the Privacy Enhanced Mail Working Group (PEM)

The PEM Working Group met at the 26th IETF, with approximately 45
attendees.  The meeting began with a status update.  It was noted that
the PEM RFCs were published in February as Proposed Standards.  The
TISPEM implementation has been available for awhile and a revised
version, with improved documentation and CRL support, will become
available in April.  Plans are underway to transition TISPEM from use of
BSAFE to RSAREF for cryptographic algorithms and to make installation
easier, especially for single- user systems.  Plans for easier
distribution of TISPEM, perhaps via anonymous FTP with suitable export
control warnings, are also under review.

PEM implementations will soon become available in the United Kingdom and
Germany as a result of work under the EC PASSPORT program.  Testing of
these implementations is taking place with the TISPEM and other PEM
implementations.  An authentication-only (MIC-ONLY and MIC-CLEAR)
version will be available from University College London (UCL) to
facilitate international distribution.  A full PEM (including
encryption) implementation is expected to be available via anonymous FTP
in Germany.

RSADSI noted that an updated PEM toolkit will be available for testing
this summer.  RSADSI announced that a ``commercial assurance PCA,'' was
suitable for use in a variety of high assurance environments.  It was
noted that users of Apple's OCE will be registered under this PCA.
RSADIS also announced the creation of a ``low assurance'' PCA with two
classes of CAs.  One class is a for CAs suitable for support of testing,
and these CAs can be registered at no cost now and at a minimal cost in
the future.  A Persona CA, operated as an automated responder, soon will
be instantiated under this PCA, providing free certificates with
unauthenticated names.

Trusted Information Systems (TIS) announced that it was planning to
operate a ``medium assurance'' PCA and had developed a draft policy
statement.  UCL observed that it was planning to become a PCA and wished
to examine the PCA statements from TIS and RSADSI in order to get a
better understanding of the form of such statements.

In addition to providing its TISPEM status update, TIS introduced two
discussion topics:  use of mailbox names, (rather than distinguished
names), in certificates and relaxing the certification hierarchy
constraints.  It was suggested that Domain Name System (DNS) names could
be encoded in X.509 certificate format by creating a new attribute, the
value of which would be a DNS mailbox name.  An alternative suggestion
was put forth to represent a mailbox name as a sequence of AVAs, each
corresponding to one component of a DNS name (plus the user name).
Several motivations for this proposal were provided, including:

                                   1





   o It permits a user to become a PEM user more easily as it does not
     require the user to determine his distinguished name

   o It allows a user to employ his existing mailbox name for
     authentication.


It was observed that this naming proposal is not likely to scale as well
as the use of true distinguished names nor does it provide users with
authenticated, descriptive identifiers.  It was suggested that the use
of DNS names in certificates might facilitate storage of certificates in
the DNS, but this claim was not substantiated.

TIS also suggested that it would be appropriate to consider relaxing the
current certification system.  The motivations cited here included a
desire to facilitate the deployment of PEM to users not connected to the
Internet and to incorporate trust models not accommodated by the current
certification system.  No specific, detailed proposals were put forth,
but TIS announced plans to make material available later.  It was
observed that if the current certification path validation rules are
substantially relaxed, the result may be a system with functionality no
better than systems such as PGP.

PEM and MIME Integration

The rest of the meeting was devoted to a discussion of the integration
of PEM and MIME. The proposal put forth by the MIME Working Group Chair
was to formally supersede RFC1421 with a specification for PEM which
requires a minimal MIME implementation.  The requirements for a
minimally compliant MIME mailer, from both submission and delivery
perspectives was presented.  Changes required relative to existing PEM
processing includes recognition of static MIME header fields, adding the
quoted-printable transformation, generation and parsing of multipart and
text content types, support of ISO 8859-n character sets, and support
for parameterized boundary markers (not compatible with the current PEM
boundary markers).

There were some strong objections to this proposal, on several grounds.
For example, the MIME-PEM specification is not yet complete and there
are a number of details in the currently published MIME-PEM
specification which are contentious (e.g., the use of inband markers for
local control of PEM submission processing and delivery indication of
applied PEM processing), so a gap of six or more months would result if
deployment 822-PEM implementations were discouraged or halted until
MIME-PEM is available.  Also, this proposal would disenfranchise
non-MIME users, which was viewed as an unacceptable result.  Other
attendees argued that they would not consider implementing 822- PEM and
would wait for MIME-PEM because of a desire to support only MIME users.

There was general agreement that it would be advantageous for users to
migrate to MIME-PEM. There was little or no support for the concept of
requiring gateways to translate between 822- PEM and MIME-PEM users.
Thus an outstanding question is whether there is any way to provide

                                   2





interoperability between 822-PEM and MIME-PEM users with minimal changes
to 822-PEM and/or minimal extensions to MIME-PEM. A related question is
the extent to which MIME-PEM can be profiled for 822 users, to minimize
the burden for such users.

The Working Group agreed that revision of the MIME-PEM specification
should be aggressively pursued with the intent that the revised
specification should be thoroughly reviewed prior to the next IETF
meeting in Amsterdam, when the PEM Working Group will meet.  In
parallel, an examination of options for 822-PEM and MIME-PEM
interoperability, e.g., minor 822-PEM revisions and suitable profiling
of MIME-PEM for use with text-only messages, will be undertaken.

Attendees

Harald Alvestrand        [e-mail]
Jules Aronson            [e-mail]
Richard Bjers            [e-mail]
Nathaniel Borenstein     [e-mail]
Sandy Bryant             [e-mail]
John Campbell            [e-mail]
William Chung            [e-mail]
Steve Dusse              [e-mail]
Antonio Fernandez        [e-mail]
Michael Fidler           [e-mail]
Barbara Fraser           [e-mail]
Ned Freed                [e-mail]
Raphael Freiwirth        [e-mail]
James Galvin             [e-mail]
Christine Garland        [e-mail]
Jisoo Geiter             [e-mail]
Terry Gray               [e-mail]
Richard Harris           [e-mail]
Gerd Holzhauer           [e-mail]
Alton Hoover             [e-mail]
Christian Huitema        [e-mail]
David Katinsky           [e-mail]
Charles Kaufman          [e-mail]
Stephen Kent             [e-mail]
Peter Kirstein           [e-mail]
Jim Knowles              [e-mail]
John Linn                [e-mail]
Kent Malave              [e-mail]
Bob Morgan               [e-mail]
Noel Nazario             [e-mail]
Emmanuel Pasetes         [e-mail]
Bradley Rhoades          [e-mail]
April Richstein          [e-mail]
Gary Rowe                [e-mail]
Jeffrey Schiller         [e-mail]
Wolfgang Schneider       [e-mail]
Einar Stefferud          [e-mail]
Stuart Stubblebine       [e-mail]

                                   3





Louisa Thomson           [e-mail]
Klaus Truoel             [e-mail]
Theodore Ts'o            [e-mail]
Gregory Vaudreuil        [e-mail]
Chuck Warlick            [e-mail]
James Weatherford        [e-mail]



                                   4