To the IESG:
The specifications for Privacy Enhanced Mail (PEM) are ready for
advancement to Proposed Standard status. Per our current rules,
attached is a description, review and recommendation of the documents.
Stephen D. Crocker
Area Director for Security
Interent Engineering Task Force
Recommendation and Analysis of the Specifications for
Privacy Enhanced Mail
There are four documents in the Privacy Enhancement for Internet
Electronic Mail series:
draft-ietf-pem-msgproc-02.txt
draft-ietf-pem-keymgmt-01.txt
draft-ietf-pem-algorithms-02.txt (*)
draft-ietf-pem-forms-01.txt
(* The revision of draft-ietf-pem-algorithms was sent separately to
internet-drafts and should appear in the Internet-Drafts directory
shortly. It was also sent to pem-dev.)
A technical summary of each of the documents is included below. The
working group summary, technical assessment, and document quality
paragraphs are the same for all documents and are presented first.
WORKING GROUP SUMMARY
The PEM specifications originated with the Privacy and Security
Research Group. As part of the transition of the specifications
from research to standards track documents a working group within
the IETF was created, which has met at each IETF since its
creation. The documents have been available as an Internet Draft
since at least September 1992 and represent the consensus of the
working group.
TECHNICAL ASSESSMENT
The PEM specifications have been under development for almost 6
years. During that time, parts of the specifications have been
published, revised and republished, with each new publication
including corrections and enhancements commensurate with the
experience obtained from implementations and continued
deliberations. The specifications have not changed dramatically
since March 1992; they are technically sound and consistent with
the internet architecture and the anticipated internet security
architecture.
This protocol opens the door for widespread use of cryptography
throughout the Internet which will result in greatly increased
security for mail traffic. This protocol is of premier importance
in the Internet and will facilitate transition of the Internet to a
robust, commercially acceptable medium.
The approach chosen in the design of this protocol is to use the
public key infrastructure defined in X.509 and encapsulation of
messages within the RFC 822 protocol. This approach makes full use
of the prior work in the CCITT and ISO community, and it fits
cleanly into the existing mail model.
There are two difficulties with the approach taken in this design.
The articulation of boundaries and parameters is particular to
the use of PEM within the RFC 822 mail protocol. MIME includes
general facilities for these functions. It would be preferable
for this protocol to be aligned with MIME. MIME was not
available at the time this protocol was designed, so it is
proceeding separately. See below for additional comments on the
alignment of MIME and PEM.
The certificate infrastructure is large and awkward to bring
into existence. It will pay off enormously in this and future
protocols because it provides an organized framework for
establishing trusted identification and binding of identities to
public keys. However, it is not easy to initiate and
necessarily slows the deployment and adoption of PEM.
Neither of these difficulties affect the soundness of the PEM
design. In the current milieu, it is important to deploy this
protocol and deal with the difficulties over a period of time.
DOCUMENT QUALITY
Although each of the PEM specifications has a different editor, they
have all cooperated to make the documents fit together as a set.
They are well written, easy to understand, and provide enough
background material to make them suitable for a security neophyte.
At the time of the third publication of the specifications, three
independent, interoperable implementations were known to exist.
Currently, only two of those are aligned with the current version of
the specifications.
One minor nit: only the Part III includes a Table of Contents.
Part I: Message Encryption and Authentication Procedures
(draft-ietf-pem-msgproc-02.txt) -- John Linn, Editor
This document defines message encryption and authentication
procedures, in order to provide privacy-enhanced mail (PEM) services
for electronic mail transfer in the Internet. It is intended to
become one member of a related set of four RFCs. The procedures
defined are intended to be compatible with a wide range of key
management approaches, including both symmetric (secret-key) and
asymmetric (public-key) approaches for encryption of data encrypting
keys. Use of symmetric cryptography for message text encryption
and/or integrity check computation is anticipated. Other documents
specify supporting key management mechanisms based on the use of
public-key certificates; algorithms, modes, and associated
identifiers; and details of paper and electronic formats and
procedures for the key management infrastructure being established in
support of these services.
Privacy enhancement services (confidentiality, authentication,
message integrity assurance, and non-repudiation of origin) are
offered through the use of end-to-end cryptography between originator
and recipient processes at or above the User Agent level. No special
processing requirements are imposed on the Message Transfer System at
endpoints or at intermediate relay sites. This approach allows
privacy enhancement facilities to be incorporated selectively on a
site-by-site or user-by-user basis without impact on other Internet
entities. Interoperability among heterogeneous components and mail
transport facilities is supported.
The current specification's scope is confined to PEM processing
procedures for the RFC-822 textual mail environment. Integration
of PEM capabilities with MIME and possibly other mail environments
is anticipated, but the specifications are yet to be worked out.
In partial anticipation of such integration, the header
"Content-Domain" with value "RFC822" is included as a hook. See
below for additional discussion.
Part II: Certificate-Based Key Management
(draft-ietf-pem-keymgmt-o1.txt) -- Stephen Kent, Editor
This document defines a supporting key management architecture and
infrastructure, based on public-key certificate techniques, to
provide keying information to message originators and recipients. It
is intended to be one member of a related set of four RFCs.
The key management architecture described is compatible with the
authentication framework described in CCITT 1988 X.509. This
document goes beyond X.509 by establishing procedures and conventions
for a key management infrastructure for use with Privacy Enhanced
Mail (PEM) and with other protocols, from both the TCP/IP and OSI
suites, in the future. The motivations for establishing these
procedures and conventions (as opposed to relying only on the very
general framework outlined in X.509) are explained in the document.
The infrastructure specified in this document establishes a single
root for all certification within the Internet, the Internet Policy
Registration Authority (IPRA). The IPRA establishes global policies,
described in this document, which apply to all certification effected
under this hierarchy. Beneath IPRA root are Policy Certification
Authorities (PCAs), each of which establishes and publishes (in the
form of an informational RFC) its policies for registration of users
or organizations. Each PCA is certified by the IPRA. Below PCAs,
Certification Authorities (CAs) will be established to certify users
and subordinate organizational entities (e.g., departments, offices,
subsidiaries, etc.). Initially, the majority of users are expected
to be registered via organizational affiliation, consistent with
current practices for how most user mailboxes are provided.
Some CAs are expected to provide certification for residential users
in support of users who wish to register independent of any
organizational affiliation. For users who wish anonymity while
taking advantage of PEM privacy facilities, one or more PCAs are
expected to be established with policies that allow for registration
of users, under subordinate CAs, who do not wish to disclose their
identities.
Part III: Algorithms, Modes, and Identifiers
(draft-ietf-pem-algorithms-02.txt) -- David Balenson, Editor
This document provides definitions, formats, references, and
citations for cryptographic algorithms, usage modes, and associated
identifiers and parameters used in support of Privacy Enhanced Mail.
It is intended to become one member of a related set of four RFCs.
It is organized into four primary sections, dealing with message
encryption algorithms, message integrity check algorithms, symmetric
key management algorithms, and asymmetric key management algorithms
(including both asymmetric encryption and asymmetric signature
algorithms). Some parts of this material are cited by other
documents and it is anticipated that some of the material herein may
be changed, added, or replaced without affecting the citing
documents.
Part IV: Key Certification and Related Services
(draft-ietf-pem-forms-01.txt) -- Burt Kaliski, Editor
This document describes three types of service in support of Internet
Privacy Enhanced Mail: key certification, certificate revocation
list (CRL) storage, and CRL retrieval. It is intended to be one
member of a related set of four RFCs.
The services described are among those required of a Certification
Authority. Each involves an electronic mail request message and an
electronic mail reply message. The request may be either a privacy
enhanced mail message or a message with a new syntax defined in this
document. The new syntax has a different process type, thereby
distinguishing it from ordinary privacy enhanced mail messages. The
reply is either a privacy enhanced mail message or an ordinary
unstructured message.
Replies that are privacy enhanced messages can be processed like any
other privacy enhanced message, so that the new certificate or the
retrieved CRLs can be inserted into the requester's database during
normal privacy enhanced mail processing.
Certification authorities may also require non-electronic forms of
the request and may return non-electronic replies. It is expected
that descriptions of such forms, which are outside the scope of this
document, will be available through a Certification Authority's
"information" service.
FUTURE DEVELOPMENTS
Integration of MIME and PEM
As noted above, it is desirable for MIME and PEM to be integrated.
Although there is great pressure to integrate these as quickly as
possible, there is even greater pressure to bring PEM out as quickly
as possible. The clear consensus is to move these specifications
forward now. In the future, proposals and trial implementations for
merged MIME-with-PEM systems will be developed, and the resulting
specifications may appear on the standards track in short order.
Compatibility between these specifications and any new specifications
will be of obvious concern. Preliminary analysis indicates that
translation between PEM into MIME-with-PEM will be trivial. In my
opinion, translation from MIME-with-PEM to PEM is also expected to be
straightforward as long as the MIME-with-PEM messages contain only
plain text, message and multipart content types.
Alternative Algorithms
Part III of these specifications define the use of the RSA, DES, MD2
and MD5 algorithms. The U.S. government is actively developing an
alternative suite of algorithms which it intends to standardize. Many
U.S. government agencies feel it will be necessary to use these
algorithms and not to use the algorithms defined in Part III of this
specification.
As a separate but related matter, the U.S. government, along with
other members of CoCom, prohibit the general export of software
containing certain forms of cryptography. In particular, software
containing DES for encryption is not generally exportable. Although
software can be developed separately in some countries to avoid the
export issue, a more general solution is to use a set of algorithms
which are exportable. Export permission has been granted for various
symmetric algorithms which are weaker than DES and for the use RSA
with limits on the key size. Of particular note, the Software
Publishers Association has reached agreement with the U.S. government
for general export of software containing RC2 and RC4 with 40 bit keys
and RSA with a limit of 512 bit keys when RSA is used for key
exchange. (There is no limit when RSA is used only for signature and
integrity.) RC2 and RC4 are symmetric key encryption algorithms
developed by RSADSI and available under license. The U.S. government
is now providing expedited processing of license requests for software
that meets these terms.
The pressure to use these alternative algorithms poses a challenge for
our community and our standards process. The introduction of new
algorithm requires substantial vetting to make sure it is technically
sound. No complete methods exist for proving the soundness of a
cryptographic algorithm, so this is necessarily a tedious and artful
process. Moreover, the use of multiple algorithms within the same
environment poses substantial compatibility problems. For these
reasons, it is desirable to set a high threshold before admitting any
additional algorithms onto the standards track. At the same time, the
pressures to incorporate additional algorithms are already evident.
Completely ignoring or prohibiting the use of alternative algorithms
will not be a successful strategy.
The Part III specification speaks to the issue of incorporation of
additional algorithms into the standard and says such incorporation
will be accomplished by issuing a successor document. Part III
specification also addresses the interim development process by
suggesting that alternative algorithms may be documented in
Experimental or Prototype RFCs prior to adoption into the standard.
As experience is gained, these protocols may be considered for
incorporation into the standard.