rfc989.txt

RFC 的详细文档！

Network Working Group                                   John Linn (BBNCC)
Request for Comments: 989                          IAB Privacy Task Force
                                                            February 1987


           Privacy Enhancement for Internet Electronic Mail:
       Part I: Message Encipherment and Authentication Procedures


STATUS OF THIS MEMO

   This RFC suggests a proposed protocol for the Internet community and
   requests discussion and suggestions for improvements.  Distribution
   of this memo is unlimited.

ACKNOWLEDGMENT

   This RFC is the outgrowth of a series of IAB Privacy Task Force
   meetings and of internal working papers distributed for those
   meetings.  I would like to thank the following Privacy Task Force
   members and meeting guests for their comments and contributions at
   the meetings which led to the preparation of this RFC: David
   Balenson, Matt Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie
   Gasser, Steve Kent (chairman), John Laws, Steve Lipner, Dan Nessett,
   Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, and Steve
   Wilbur.

1  Executive Summary

   This RFC defines message encipherment and authentication procedures,
   as the initial phase of an effort to provide privacy enhancement
   services for electronic mail transfer in the Internet.  Detailed key
   management mechanisms to support these procedures will be defined in
   a subsequent RFC.  As a goal of this initial phase, it is intended
   that the procedures defined here be compatible with a wide range of
   key management approaches, including both conventional (symmetric)
   and public-key (asymmetric) approaches for encryption of data
   encrypting keys.  Use of conventional cryptography for message text
   encryption and/or authentication is anticipated.

   Privacy  enhancement services (confidentiality, authentication, and
   message integrity assurance) are offered through the use of end-to-
   end cryptography between originator and recipient User Agent
   processes, with no special processing requirements imposed on the
   Message Transfer System at endpoints or at intermediate relay sites.
   This approach allows privacy enhancement facilities to be
   incorporated 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.





Linn, Privacy Task Force                                        [Page 1]

RFC 989                                                    February 1987


2  Terminology

   For descriptive purposes, this RFC uses some terms defined in the OSI
   X.400 Message Handling System Model.  This section replicates a
   portion of X.400's Section 2.2.1, "Description of the MHS Model:
   Overview" in order to make the terminology clear to readers who may
   not be familiar with the OSI MHS Model.

   In the [MHS] model, a user is a person or a computer application.  A
   user is referred to as either an originator (when sending a message)
   or a recipient (when receiving one).  MH Service elements define the
   set of message types and the capabilities that enable an originator
   to transfer messages of those types to one or more recipients.

   An originator prepares messages with the assistance of his User
   Agent.  A User Agent (UA) is an application process that interacts
   with the Message Transfer System (MTS) to submit messages.  The MTS
   delivers to one or more recipient UAs the messages submitted to it.
   Functions performed solely by the UA and not standardized as part of
   the MH Service elements are called local UA functions.

   The MTS is composed of a number of Message Transfer Agents (MTAs).
   Operating together, the MTAs relay messages and deliver them to the
   intended recipient UAs, which then make the messages available to the
   intended recipients.

   The collection of UAs and MTAs is called the Message Handling System
   (MHS).  The MHS and all of its users are collectively referred to as
   the Message Handling Environment.

3  Services, Constraints, and Implications

   This RFC's goal is to define mechanisms to enhance privacy for
   electronic mail transferred in the Internet.  The facilities
   discussed in this RFC provide privacy enhancement services on an
   end-to-end basis between sender and recipient UAs.  No privacy
   enhancements are offered for message fields which are added or
   transformed by intermediate relay points.  Two distinct privacy
   enhancement service options are supported:

      1.  an option providing sender authentication and integrity
          verification

      2.  an option providing sender authentication and integrity
          verification in addition to confidentiality service through
          encryption

   No facility for confidentiality service in the absence of
   authentication is provided.  Encryption and authentication facilities
   may be applied selectively to portions of a message's contents; this
   allows less sensitive portions of messages (e.g., descriptive fields)



Linn, Privacy Task Force                                        [Page 2]

RFC 989                                                    February 1987


   to be processed by a recipient's delegate in the absence of the
   recipient's personal cryptographic keys.

   In keeping with the Internet's heterogeneous constituencies and usage
   modes, the measures defined here are applicable to a broad range of
   Internet hosts and usage paradigms.  In particular, it is worth
   noting the following attributes:


        1.   The mechanisms defined in this RFC are not restricted to a
             particular host or operating system, but rather allow
             interoperability among a broad range of systems.  All
             privacy enhancements are implemented at the application
             layer, and are not dependent on any privacy features at
             lower protocol layers.

        2.   The defined mechanisms offer compatibility with non-
             enhanced Internet components.  Privacy enhancements will be
             implemented in an end-to-end fashion which does not impact
             mail processing by intermediate relay hosts which do not
             incorporate privacy enhancement facilities.  It is
             necessary, however, for a message's sender to be cognizant
             of whether a message's intended recipient implements
             privacy enhancements, in order that encoding and possible
             encipherment will not be performed on a message whose
             destination is not equipped to perform corresponding
             inverse transformations.

        3.   The defined mechanisms offer compatibility with a range of
             mail transport facilities (MTAs).  Within the Internet,
             electronic mail transport is effected by a variety of SMTP
             implementations.  Certain sites, accessible via SMTP,
             forward mail into other mail processing environments (e.g.,
             USENET, CSNET, BITNET).  The privacy enhancements must be
             able to operate across the SMTP realm; it is desirable that
             they also be compatible with protection of electronic mail
             sent between the SMTP environment and other connected
             environments.

        4.   The defined mechanisms offer compatibility with a broad
             range of electronic mail user agents (UAs).  A large
             variety of electronic mail user agent programs, with a
             corresponding broad range of user interface paradigms, is
             used in the Internet.  In order that an electronic mail
             privacy enhancement be available to the broadest possible
             user community, it is desirable that the selected mechanism
             be usable with the widest possible variety of existing UA
             programs.  For purposes of pilot implementation, it is
             desirable that privacy enhancement processing be
             incorporable into a separate program, applicable to a range
             of UAs, rather than requiring internal modifications to



Linn, Privacy Task Force                                        [Page 3]

RFC 989                                                    February 1987


             each UA with which enhanced privacy services are to be
             provided.

        5.   The defined mechanisms allow electronic mail privacy
             enhancement processing to be performed on personal
             computers (PCs) separate from the systems on which UA
             functions are implemented.  Given the expanding use of PCs
             and the limited degree of trust which can be placed in UA
             implementations on many multi-user systems, this attribute
             can allow many users to process privacy-enhanced mail with
             a higher assurance level than a strictly UA-based approach
             would allow.

        6.   The defined mechanisms support privacy protection of
             electronic mail addressed to mailing lists.

   In order to achieve applicability to the broadest possible range of
   Internet hosts and mail systems, and to facilitate pilot
   implementation and testing without the need for prior modifications
   throughout the Internet, three basic restrictions are imposed on the
   set of measures to be considered in this RFC:


          1.   Measures will be restricted to implementation at
               endpoints and will be amenable to integration at the user
               agent (UA) level or above, rather than necessitating
               integration into the message transport system (e.g., SMTP
               servers).

          2.   The set of supported measures enhances rather than
               restricts user capabilities.  Trusted implementations,
               incorporating integrity features protecting software from
               subversion by local users, cannot be assumed in general.
               In the absence of such features, it appears more feasible
               to provide facilities which enhance user services (e.g.,
               by protecting and authenticating inter-user traffic) than
               to enforce restrictions (e.g., inter-user access control)
               on user actions.

          3.   The set of supported measures focuses on a set of
               functional capabilities selected to provide significant
               and tangible benefits to a broad user community.  By
               concentrating on the most critical set of services, we
               aim to maximize the added privacy value that can be
               provided with a modest level of implementation effort.

   As a result of these restrictions, the following facilities can be
   provided:

         -- disclosure protection,




Linn, Privacy Task Force                                        [Page 4]

RFC 989                                                    February 1987


         -- sender authenticity, and

         -- message integrity measures,

   but the following privacy-relevant concerns are not addressed:

         -- access control,

         -- traffic flow security,

         -- address list accuracy,

         -- routing control,

         -- issues relating to the serial reuse of PCs by multiple users,

         -- assurance of message receipt and non-deniability of receipt, and

         -- automatic association of acknowledgments with the messages to
            which they refer

   An important goal is that privacy enhancement mechanisms impose a
   minimum of burden on the users they serve.  In particular, this goal
   suggests eventual automation of the key management mechanisms
   supporting message encryption and authentication.  In order to
   facilitate deployment and testing of pilot privacy enhancement
   implementations in the near term, however, compatibility with out-
   of-band (e.g., manual) key distribution must also be supported.

   A message's sender will determine whether privacy enhancements are to
   be performed on a particular message.  This will necessitate
   mechanisms by which a sender can determine whether particular
   recipients are equipped to process privacy-enhanced mail.  In a