From: gnu (John Gilmore)
Date: Fri, 29 Jan 93 13:03:42 PST
To: cypherpunks
Subject: Privacy Enhanced Mail proceeds to Proposed Standard
Message-ID: <9301292103.AA11818@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


------- Forwarded Message

To: Jon Postel -- RFC Editor <postel@isi.edu>
To: IETF-Announce:;@CNRI.Reston.VA.US@TIS.COM
Cc: Internet Architecture Board <iab@isi.edu>
Cc: pem-dev@TIS.COM
Cc: The Internet Engineering Steering Group <IESG@IETF.CNRI.Reston.VA.US>
From: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US>
Subject: Protocol Action: Privacy Enhanced Mail to Proposed Standard
Date: Fri, 29 Jan 93 14:29:02 -0500
Message-Id:  <9301291429.aa07535@IETF.CNRI.Reston.VA.US>

   The IESG has approved the Privacy Enhanced Mail Protocols as a 
   Proposed Standard.  These protocols are defined in the Internet Drafts:

   o "Privacy Enhancement for Internet Electronic Mail:  Part I: Message
     Encryption and Authentication Procedures" <draft-ietf-pem-msgproc-02.txt>

   o "Privacy Enhancement for Internet Electronic Mail: Part II:
     Certificate-Based Key Management" <draft-ietf-pem-keymgmt-01.txt>

   o "Privacy Enhancement for Internet Electronic Mail: Part III:
     Algorithms, Modes, and Identifiers" <draft-ietf-pem-algorithms-02.txt>

   o "Privacy Enhancement for Internet Electronic Mail:  Part IV: Key
     Certification and Related Services" <draft-ietf-pem-forms-01.txt>

   These documents are the product of the Privacy-Enhanced Electronic
   Mail Working Group. The IESG contact person is Steve Crocker.

Technical Summary

   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.

THE DOCUMENTS

 o Part 1, Message Encryption and Authentication Procedures

   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.  Symmetric cryptography is used for message text encryption.
   Cryptographic hash algorithms are used for message integrity check
   value computation.  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

   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

   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

   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.


THE USE OF CERTIFICATES AND PRIVATE KEYS

   To aid in understanding the roles of public keys, certificates and
   private keys, it is useful to consider four functions:

   - Sealing and signing a message.  
   - Verifying the integrity and signature of a message.  
   - Encrypting a message to ensure confidentiality.  
   - Decrypting a confidential message.

   The protocols are designed so that sealing and signing are the base
   protocol, and encryption is an optional addition.  That is, a
   privacy enhanced message is always signed and is only optionally
   encrypted.

   To sign a message, the sender must have a public/private key pair.
   The sender uses the private key to sign the message.  Receivers use
   the corresponding public key to check the signature.  With respect
   to the issuance and use of certificates, only the sender need have a
   certificate.  Receivers use the sender's certificate to ascertain
   the sender's public key, and hence may check the integrity and
   authenticity of a message irrespective if whether they have a
   certificate.  This arrangement makes it possible for a sender to
   sign a public message, e.g. to a newsgroup, and each recipient may
   check the integrity and signature of the message.

   License agreements for RSAREF from RSA and TIS/PEM from TIS permit
   the use of their software for this purpose at no cost, as long as
   the software is not sold.  

   Encryption and decryption are a different matter.  To send an
   encrypted message, each receiver must have a private/public key
   pair. The sender accesses the receiver's public key and encrypts the
   message so only the receiver can decrypt the message.  Since
   encryption is designed as an optional additional to the integrity
   and signature process, the use of encryption necessarily implies
   both the sender and receiver have private/public key pairs.

   There is one exception to this rule.  The PEM specifications also
   permit a symmetric key algorithm to be used for encryption.  This is
   suitable for traffic between two parties who have manually exchanged
   keys previously.  DES is the algorithm used for this purpose, and it
   is in the public domain.


A COMMENT ON THE DECISION TO INCORPORATE PATENTED TECHNOLOGY.

   Some have asked whether it is necessary to incorporate a patented
   technology into the standard.  In a very real sense, the idea of
   wide scale cryptography in a public, networked environment is not
   viable without public key technology.  Public key technology opened
   up the field and enabled application not previously possible.
   Hence, the decision was not whether to choose public key technology
   versus some other technology.  Rather, the decision was to develop
   privacy enhanced mail once public key technology became available.

   The patent situation for public key technology is a bit strange.
   The patent rules vary slightly from country to country.  The basic
   ideas for public key cryptography were published before the patent
   was applied for.  In the U.S., there is a one year period in which
   it is still possible to apply for patents after publication.
   Elsewhere, publication prohibits patenting.  Hence, the patent
   governing RSA applies in the U.S. (and perhaps Canada) but not
   elsewhere in the world.

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 expectEed 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.

PATENT STATEMENT

   The IESG has reviewed the patent issues and will have the following
   text added to each of the RFC documents:

   This version of Privacy Enhanced Mail (PEM) relies on the use of
   patented public key encryption technology for authentication and
   encryption.  The Internet Standards Process as defined in RFC 1310
   requires a written statement from the Patent holder that a license will
   be made available to applicants under reasonable terms and conditions
   prior to approving a specification as a Proposed, Draft or Internet
   Standard.

   The Massachusetts Institute of Technology and the Board of Trustees of
   the Leland Stanford Junior University have granted Public Key Partners
   (PKP) exclusive sub-licensing rights to the following patents issued in
   the United States, and all of their corresponding foreign patents:

      Cryptographic Apparatus and Method
      ("Diffie-Hellman")............................... No. 4,200,770

      Public Key Cryptographic Apparatus
      and Method ("Hellman-Merkle").................... No. 4,218,582

      Cryptographic Communications System and
      Method ("RSA")................................... No. 4,405,829

      Exponential Cryptographic Apparatus
      and Method ("Hellman-Pohlig").................... No. 4,424,414

   These patents are stated by PKP to cover all known methods of
   practicing the art of Public Key encryption, including the variations
   collectively known as El Gamal.

   Public Key Partners has provided written assurance to the Internet
   Society that parties will be able to obtain, under reasonable, 
   nondiscriminatory terms, the right to use the technology covered by
   these patents.  This assurance is documented in RFC-1170 titled "Public
   Key Standards and Licenses".  A copy of the written assurance dated
   April 20, 1990, may be obtained from the Internet Assigned Number
   Authority (IANA).

   The Internet Society, Internet Architecture Board, Internet Engineering
   Steering Group and the Corporation for National Research Initiatives
   take no position on the validity or scope of the patents and patent
   applications, nor on the appropriateness of the terms of the
   assurance.  The Internet Society and other groups mentioned above have
   not made any determination as to any other intellectual property rights
   which may apply to the practice of this standard. Any further
   consideration of these matters is the user's own responsibility.


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.

Protocol 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.


Greg Vaudreuil
IESG Secretary

------- End of Forwarded Message