Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures
RFC 989

Document Type RFC - Unknown (February 1987; No errata)
Obsoleted by RFC 1040, RFC 1113
Last updated 2013-03-02
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 989 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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


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


   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

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

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

   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
Show full document text