------- Forwarded Message
To: Jon Postel -- RFC Editor <postel(a)isi.edu>
To: IETF-Announce:;@CNRI.Reston.VA.US@TIS.COM
Cc: Internet Architecture Board <iab(a)isi.edu>
Cc: pem-dev(a)TIS.COM
Cc: The Internet Engineering Steering Group <IESG(a)IETF.CNRI.Reston.VA.US>
From: IESG Secretary <iesg-secretary(a)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(a)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
