Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures
RFC - Unknown
(February 1987; No errata)
||RFC Editor Note
RFC 989 (Unknown)
||Send notices to
Network Working Group John Linn (BBNCC)
Request for Comments: 989 IAB Privacy Task Force
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.
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
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
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