PEM WG MEETING MINUTES (14-7-93)
1. PEM Implementation Status Report
- TIS
TISPEM is now available via anonymous FTP and the distribution
includes CA software. The TIS U.K. office is working on a commercial
PEM implementation to be made available in Europe.
- MIT
TechMail with PEM, a Mac PEM implementation integrated with a Mac
email system, will be available very soon via anonymous FTP. TechMail
requires POP3 server and has been shown to interoperate with TISPEM.
Ray Lau, a well-known Mac software developer, has developed a
standalone version of PEM software for the Mac which may be available
soon.
- 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 TISPEM.
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 email 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.
- 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, Stockholm. They are performing interoperability tests with
TIS. A smart card version is being developed.
- RSADSI
A new TIPEM (commercial product) version in beta now and should
be available in 8-12 weeks. The Certificate Issuing Systems (a
commercial product) software and hardware will be commercially
available in 6-8 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.
2. MIME-PEM Discussion
It was the intent of this PEM WG 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 I-D
and prepare comments for this meeting. Unfortunately, the I-D
available immediately prior to the meeting did not reflect changes
discussed at the last WG meeting and in subsequent PEM-DEV mailing
list discussion. Thus no substantive progress was made on this topic.
Both Linn and Schiller 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 in embedded in these complex messages.
Both observed that one possible means of simplifying the MIME-PEM
"integration problem" is to treat a 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 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 1421 data to be a body part, as suggested
above. An analysis by Crocker and Rose 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 1421 message format.
However, if a 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 a 1421 message or initially a
MIME-PEM message.
There was no resolution of these issues. There was agreement
that a new MIME-PEM I-D must be written to reflect the recent improved
understanding of these problems, and to reflect the comments of the
previous PEM WG meetings. A proposal for a simple, MIME encapsulation
of 1421 messages may be developed, but no authors were identified.
3. Certificate Name Discussion
At the previous PEM WG 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 notes.
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.
4. Certification System Discussion
At the previous PEM WG 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 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.
5. Algorithm Discussion
There was extensive discussion of ways to use "tripe-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 (email) 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
WG.
No resolution of this issue was reached at this meeting.
---------------------------------------------------------------
Material presented for item #3:
"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 email 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
email 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.
----------------------------------------------------------------------
Material prepared for item #4:
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.