Recommendation of advancement of PEM specs

[Stephen D Crocker <[e-mail]>]

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.