PEM Working Group Meeting Minutes 4/1/93
The PEM WG met at the 26th IETF, with approximately 45
attendees. The meeting began with status update. It was noted
that the PEM RFCs were published in February as proposed
standards. The TISPEM implementation has been available for a
while 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 UK 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 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," suitable for use in a variety 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.
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 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:
- it permits a user to become a PEM user more easily as it
does not require the user to determine his distinguished name
- and 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.
The rest of the meeting was devoted to a discussion of the
integration of PEM and MIME. The proposal put forth by the MIME
WG chair was to formally supersede RFC 1421 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 interoperability between 822-PEM and
MIME-PEM users with minimal changes to 822-PEM and/or minimal
extensions to MIME-PEM. A related question the extent to which
MIME-PEM can be profiled for 822 users, to minimize the burden
for such users.
The WG 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 WG 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.