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