CURRENT_MEETING_REPORT_
Reported by Steve Kent/BBN
Minutes of the Privacy Enhanced Mail Working Group (PEM)
PEM Implementation Status Report
o TIS
TIS/PEM is now available via anonymous FTP and the distribution
includes CA software. The TIS UK office is working on a commercial
PEM implementation to be made available in Europe.
o MIT
TechMail with PEM, a Mac PEM implementation integrated with a Mac
e-mail system, will be available very soon via anonymous FTP.
TechMail requires a POP3 server and has been shown to interoperate
with TIS/PEM. Ray Lau, a well-known Mac software developer, has
developed a stand-alone version of PEM software for the Mac which
may be available soon.
o PASSWORD Project
Three Unix PEM implementations are now available, and a fourth is
on the way as a result of this EC-sponsored project. The
implementations are from UCL, Cambridge University, INRIA, and GMD.
All can make use of X.500 directories and all include CA software.
All the implementations interoperate with one another and there
have been some interworking tests with TIS/PEM.
The UCL version is ``somewhat'' integrated with MH and runs on a
SPARC now.
The GMD version is part of a larger security tool kit, using a
variety of algorithms, and secure (strong authentication) X.500
operations. The GMD implementation is a standalone version that is
not integrated into an e-mail system, although it is integrated
with X.500 directory access code to fetch certificates and CRLs.
It will be available via anonymous FTP (subject to COCOM
restrictions). There are plans to establish a PCA for academic
users within Germany.
The Cambridge version supports symmetric key management as well as
asymmetric key management (using RSA). The Cambridge version is the
subject of experimentation with other algorithm suites, e.g., DSA
and SHA. It also works without access to a directory server.
o COST (Sweden)
This commercial PEM implementation runs on DEC and Sun
workstations, includes CA software, and includes a centralized
certificate server for all COST/PEM users. COST intends to run its
own PCA. COST/PEM is now undergoing beta testing at universities in
Dublin and Stockholm. They are performing interoperability tests
with TIS. A smart card version is being developed.
o RSADSI
A new TIPEM (commercial product) version is in beta now and should
be available in eight to twelve weeks. The Certificate Issuing
Systems (a commercial product) software and hardware will be
available in six to eight weeks. A description of the RSADSI plans
for operating a low-assurance PCA with two CAs will be available
very soon. One CA (a free service) under this PCA will be a
PERSONA CA and it is now operating on a trial basis; a second
(non-PERSONA) CA will become operational soon along with a policy
statement available via FTP. A commercial PCA, using the CIS noted
above, will be available soon, and the policy for that PCA also
will be available soon.
MIME-PEM Discussion
It was the intent of this PEM Working Group meeting to review the latest
technical proposal (Internet-Draft) for MIME-PEM integration, as
announced in the agenda distributed several weeks prior to the meeting.
John Linn and Jeff Schiller were asked to review this Internet-Draft and
prepare comments for this meeting. Unfortunately, the Internet-Draft
available immediately prior to the meeting did not reflect changes
discussed at the last working group meeting and in subsequent pem-dev
mailing list discussion. Thus no substantive progress was made on this
topic.
Both John and Jeff expressed concern about the continued presence of
inline ``optional'' fields to indicate the PEM processing to be applied,
or to indicate the PEM processing that has been applied to a message.
They also expressed concern about ``distinguished encoding'' problems
that may arise in complex MIME messages where a signature might
encompass MIME headers embedded in these complex messages. Both
observed that one possible means of simplifying the MIME-PEM
``integration problem'' is to treat an RFC 1421 ``message'' as a body
part to be carried by MIME. This might not offer all of the flexibility
of the recent proposals, but it would significantly simplify both
processing and backward compatibility for RFC 822-PEM implementations.
Steve Crocker presented several technical points related to the
structure of MIME-PEM messages, based on a very recent meeting with
Marshall Rose. There was agreement that signatures on complex MIME
objects cannot be effected as previously proposed, and that new
application type MIME objects were required to ``protect'' signed data
from possible manipulation by MIME relays.
He agreed that representing PEM messages as application context types
would allow RFC 1421 data to be a body part, as suggested above. An
analysis by Steve Crocker and Marshall suggested that a (MIME) message
reader can easily distinguish among a vanilla text message, a MIME
message, or a PEM-MIME message. Disambiguation would require
introduction of an additional blank line into the RFC 1421 message
format. However, if an RFC 1421 message were to pass through an
intermediate MIME relay, it might be transformed in a way that would
make it ambiguous as to whether this was initially an RFC 1421 message
or initially a MIME-PEM message.
There was no resolution of these issues. There was agreement that a new
MIME-PEM Internet-Draft must be written to reflect the recent improved
understanding of these problems, and to reflect the comments of the
previous PEM Working Group meetings. A proposal for a simple, MIME
encapsulation of RFC 1421 messages may be developed, but no authors were
identified.
Certificate Name Discussion
At the previous PEM Working Group meeting, Steve Crocker initiated a
discussion of the form of names that should appear in certificates used
in PEM. He advocated the use of domain name system (DNS) mailbox names
in lieu of distinguished names (DNs). This discussion took the form of
several hand-written slides that were reported upon in the meeting
minutes, but there was no written follow-up on the pem-dev mailing list.
In response to this previous presentation, Steve Kent assembled material
to compare the use of DNS names and DNs. Due to time constraints, only
some of this material was presented during the meeting. All of the material
is included at the end of these minutes. This material argues that many
(though not all) of the objections previously raised to the use of DNs
can be addressed through good PEM implementation practice and that the
use of DNs offers a number of advantages relative to the use of DNs.
Certification System Discussion
At the previous PEM Working Group meeting, Steve Crocker also initiated
a discussion of the concept of relaxing some of the constraints imposed
by the PEM certificate management system (RFC 1422). This discussion
took the form of several hand-written slides that were reported upon in
the meeting minutes, but there was no written follow-up on the pem-dev
mailing list. In response to this previous presentation, Steve Kent
assembled material to review some of the rationale that underlies the
current certification system. Due to time constraints, none of this
material was presented. The material is included at the end of these
notes.
Algorithm Discussion
There was extensive discussion of ways to use ``triple-DES'' on the
pem-dev mailing list prior to this meeting. Mike Roe made a brief
presentation on triple-DES options and distributed to attendees an
extensive analysis he had prepared. There is agreement that use of EDE
as a codebook is intrinsically slower than approaches that perform
multiple chaining passes, if parallel hardware is employed. However, in
the PEM (e-mail) context it is not clear that this performance
improvement is a significant factor, especially if software DES (not
executed in parallel on multiple processors) is the dominant
implementation mode. In this context, the various triple-DES options
are essentially equivalent in performance.
It was suggested that the primary motivation for using triple-DES is
security, not performance. Although there is significant literature
supporting the security of EDE as a codebook, there is little if any
analysis of the security of the other proposed modes. It was announced
that RSA Labs will perform a study of the security of the different
proposed modes and make a report available to the PEM Working Group.
No resolution of this issue was reached at this meeting.
Attendees
Harald Alvestrand Harald.Alvestrand@uninett.no
Frederik Andersen fha@dde.dk
James Conklin jbc@bitnic.educom.edu
Stephen Crocker crocker@tis.com
Maria Dimou-Zacharova dimou@dxcern.cern.ch
Kishan Dudkikar kishan@icm1.icp.net
Steve Dusse spock@rsa.com
Barbara Fraser byf@cert.org
James Galvin galvin@tis.com
Tim Goodwin tim@pipex.net
Richard Graveman rfg@ctt.bellcore.com
Neil Haller nmh@thumper.bellcore.com
Alton Hoover hoover@ans.net
Nada Kapidzic nadak@dsv.su.se
Stephen Kent kent@bbn.com
Peter Kirstein P.Kirstein@cs.ucl.ac.uk
Jim Knowles jknowles@binky.arc.nasa.gov
Arjen Lenstra lenstra@bellcore.com
John Linn linn@gza.com
Kim Chr. Madsen kimcm@ic.dk
Keith Moore moore@cs.utk.edu
Michael Roe mrr@cl.cam.ac.uk
Jeffrey Schiller jis@mit.edu
Wolfgang Schneider schneiw@darmstadt.gmd.de
Robert Shirey shirey@mitre.org
Theodore Ts'o tytso@mit.edu
Lea Viljanen Lea.Viljanen@helsinki.fi
Erik Zegwaart zegwaart@surfnet.nl
James Zmuda zmuda@mls.hac.com
Appendix One
Material presented for the "Certificate Name Discussion'':
``Features'' for Names Used in Certificates
Feature Distinguished Domain
Name Name
globally unique YES YES
distributed generation YES YES
descriptive YES NO->SOMEWHAT
naming infrastructure SPARSE EXTENSIVE
storage infrastructure GROWING EXTENSIVE
mailbox independent YES NO->SOMEWHAT
easy to remember MAYBE MAYBE
easy to deduce MAYBE MAYBE
easy to type NO YES
- From a message submission perspective, a good PEM
implementation should accept DNS names, DNs, or local alia ses as
input from user to select recipients. All three forms could be mapped
locally to the name form used in certificates. Many users make
extensive use of local aliases, in which case mapping to a DN or a DNS
name is equally easy. If DNs are used, one can help avoid suppress by
allowing the sender to review the certificate names (prior to
submission) to avoid the ``I securely sent the message to the wrong
recipient'' phenomenon.
- Received e-mail will always contain DNS names, but the name in
the certificate is what is authenticated. One can argue that if both
names are the same this makes it easier for the user (or software) to
check, and hence DNS names should be favored. However, because mail
systems sometimes translate DNS names in headers, often there may not
be a 1-1 correspondence between the DNS name that appears in an 822
header for different recipients and that seen by the originator.
Also, if a sender wants to employ the same certificate to send/receive
mail at various mailboxes, or for persona certificate users, there
cannot always be a direct correspondence between the mailbox name and
the name contained in a certificate.
- Although DNs are longer and more awkward to type than DNS
names, a good PEM implementation would require a u ser to enter the
name of a recipient at most once, and maybe never. For example,
consider receipt of a certificate in a PEM message from a user with
whom the recipient has not previously corresponded. A good PEM
implementation can query the recipient for a (local) name to be
assigned to the sender, thus avoiding any requirement for the
recipient to type the certificate name associated with this sender.
This local name could be an alias or could be the DNS name, at the
discretion of the recipient.
- If name subordination is to be maintained as a requirement for
certificate validation below the PCA tier, th en this may be more
easily done using DNs than DNS names, although this depends on details
of organizational structure and DNS domain organization.
- Some have complained that using a DN vs. a DNS name somehow
usurps a user's ability to be represented by hi s existing DNS name.
But messages continue to carry the same DNS names for originator and
recipients as before. Also, many messages carry a commented ``more
descriptive individual name'' adjacent to the originator's DNS name in
the message header and some carry elaborate trailers providing
organizational affiliation. Thus, some significant percentage of
e-mail users already seem to feel that DNS names are not sufficiently
descriptive.
- It has been suggested that if DNs appear in certificates then
the certificates must be stored in X.500 dire ctories. This is not
correct. Certificates containing DNs (or DNS names) might be stored
in various databases, e.g., whois++ or DNS servers, not only in X.500
directories. Certificates can be compressed to save space and/or
encoded to permit storage in ASCII- only databases. Certificates can
be retrieved based on any search key convenient for users. The
fundamental requirement is that the name contained in the certificate
be sufficiently descriptive so that the user can verify that the
certificate retrieved corresponds to the entity in question,
irrespective of the search key used.
Appendix Two
Material prepared for the ``Certification System Discussion'':
PEM Certification Infrastructure ``Features''
- support for diverse policies
In the global Internet environment, certificates will be issued
under a number of different policies. The policies will differ based
on the rigor with which organizational or individual identities are
verified, CRLs are maintained, CA keys are generated and protected,
etc. The certification infrastructure must accommodate this
diversity, ranging from high assurance policies suitable for use in
business and official government contexts, to persona policies. The
current architecture achieves this through the use of Policy CAs
(PCAs).
- alerting users to trust policies
Users must be made aware of the differences in trust policies, so
that they can make informed decisions as to the trustworthiness of the
identity information contained in a certificate. It must be possible
for any user to determine (unambiguously) the policy under which any
certificate was issued. The means by which a user is alerted to these
differences should be simple, uniform, and automated. The current
architecture achieves this through the use of PCAs, prohibition of
cross-certification, and the requirement that PCA policies be
available on-line.
- ``what you see if what you believe'' principle
We expect a recipient of a message to pay only minimal attention
to the authentication information presented by PEM. At a minimum the
name from the originator's certificate, or a local alias assigned to
this name, should be displayed. The current architecture fulfills
this requirement through display of the originator's distinguished
name (or a local alias thereof). For an originator not already known
to the recipient, this display not only uniquely identifies the
originator, but also identifies superior CAs (because of the DN name
subordination rule). Since different policies are supported, some
form of identification of the policy under which this certificate was
issued must be displayed. In the current architecture, this is
effected by displaying the PCA's DN, or a local alias thereof. The
combination of these two identifying data items provides a recipient
with a fairly complete picture of the originator's identity.
- minimizing trust in CAs
In any distributed certification system, there is a valid concern
about the extent of damage that can result from malicious or careless
certification practices by a certifying authority. The signing of a
certificate provides a basis for non-repudiable evidence of the
(certification) actions of any certification authority. However,
additional ``rules of conduct'' are required to establish generic
expectations for certification authority behavior, especially in an
architecture that admits a variety of certification policies.
In the current architecture, the IPRA operates under a very
straightforward policy in its certification of PCAs. The IPRA uses
highly secure technology to generate and protect the private key it
uses to sign PCA certificates, and employs stringent security
procedures to protect the signing process.
In the current architecture, PCAs are allowed greater leeway in
defining the protection they afford to the keys used to sign CA
certificates, and other security policy issues, but the PCAs are
required to publish these procedures so that users can personally
evaluate the quality of security afforded by PCAs and the CAs they
certify. The IPRA requires PCAs to co-operate to ensure the
uniqueness of the (distinguished) names of the entities they certify.
This establishes a clear PCA responsibility and egregious failure to
abide by this requirement constitutes cause for de-certifying a PCA.
Each CA is required to issue certificates only for entities that are
(distinguished) name subordinated to the CA. This requirement
prevents a CA from issuing a certificate to a user (or a CA) that is
not related to the CA in an obvious, syntactic fashion. This
restricts the damage that a careless or malicious CA can do, by
limiting the scope of certification of each CA.
- uniform certification processing rules
Although certification policies differ, it is important to employ
a uniform algorithm for validating certificates. This algorithm
should be simple, both to minimize the likelihood of implementation
errors and to make the validation process understandable by users. In
the current architecture, the validation rules are consistent across
PCA boundaries and for all CAs, despite policy differences. This
certification system is simple, with explicit recognition of IPRA, PCA
and CA tiers. The IPRA public key is the root of the certification
system and thus is ``built into'' an implementation. A PCA, CA, or user
certificate is validated relative to its issuer's public key in all
cases. A user certificate, or a certificate for a CA subordinate to
another CA (vs. a PCA), must also be checked for subordination
relative to it's issuer.