rfc1421.txt

RFC 的详细文档！

Network Working Group                                            J. Linn
Request for Comments: 1421                    IAB IRTF PSRG, IETF PEM WG
Obsoletes: 1113                                            February 1993


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

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Acknowledgements

   This document is the outgrowth of a series of meetings of the Privacy
   and Security Research Group (PSRG) of the IRTF and the PEM Working
   Group of the IETF.  I would like to thank the members of the PSRG and
   the IETF PEM WG, as well as all participants in discussions on the
   "[e-mail]" mailing list, for their contributions to this
   document.

1.  Executive Summary

   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 in the current document 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.  Use of symmetric cryptography for message text
   encryption and/or integrity check computation is anticipated. RFC
   1422 specifies supporting key management mechanisms based on the use
   of public-key certificates.  RFC 1423 specifies algorithms, modes,
   and associated identifiers relevant to the current RFC and to RFC
   1422.  RFC 1424 provides 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



Linn                                                            [Page 1]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   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, and defines the
   Content-Domain indicator value "RFC822" to signify this usage.
   Follow-on work in integration of PEM capabilities with other
   messaging environments (e.g., MIME) is anticipated and will be
   addressed in separate and/or successor documents, at which point
   additional Content-Domain indicator values will be defined.

2.  Terminology

   For descriptive purposes, this RFC uses some terms defined in the OSI
   X.400 Message Handling System Model per the CCITT Recommendations.
   This section replicates a portion of (1984) 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 or her
   User Agent (UA).  A 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.







Linn                                                            [Page 2]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


3.  Services, Constraints, and Implications

   This RFC defines 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
   originator and recipient processes residing at the UA level or above.
   No privacy enhancements are offered for message fields which are
   added or transformed by intermediate relay points between PEM
   processing components.

   If an originator elects to perform PEM processing on an outbound
   message, all PEM-provided security services are applied to the PEM
   message's body in its entirety; selective application to portions of
   a PEM message is not supported. Authentication, integrity, and (when
   asymmetric key management is employed) non-repudiation of origin
   services are applied to all PEM messages; confidentiality services
   are optionally selectable.

   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 are compatible with non-enhanced
            Internet components.  Privacy enhancements are 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 originator to be
            cognizant of whether a message's intended recipient
            implements privacy enhancements, in order that encoding and
            possible encryption will not be performed on a message whose
            destination is not equipped to perform corresponding inverse
            transformations.  (Section 4.6.1.1.3 of this RFC describes a
            PEM message type ("MIC-CLEAR") which represents a signed,
            unencrypted PEM message in a form readable without PEM
            processing capabilities yet validatable by PEM-equipped
            recipients.)

        3.  The defined mechanisms are compatible with a range of mail
            transport facilities (MTAs).  Within the Internet,



Linn                                                            [Page 3]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


            electronic mail transport is effected by a variety of SMTP
            [2] 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 are compatible 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 electronic mail privacy
            enhancements be available to the broadest possible user
            community, selected mechanisms should 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 each UA with which PEM
            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 PEM with a higher assurance level than a strictly
            UA-integrated approach would allow.

        6.  The defined mechanisms support privacy protection of
            electronic mail addressed to mailing lists (distribution
            lists, in ISO parlance).

        7.  The mechanisms defined within this RFC are compatible with a
            variety of supporting key management approaches, including
            (but not limited to) manual pre-distribution, centralized
            key distribution based on symmetric cryptography, and the
            use of public-key certificates per RFC 1422.  Different
            key management mechanisms may be used for different
            recipients of a multicast message.  For two PEM
            implementations to interoperate, they must share a common
            key management mechanism; support for the mechanism defined
            in RFC 1422 is strongly encouraged.





Linn                                                            [Page 4]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   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 and pervasive
   modifications throughout the Internet, the following design
   principles were applied in selecting the set of features specified in
   this RFC:

        1.  This RFC's measures are restricted to implementation at
            endpoints and are amenable to integration with existing
            Internet mail protocols at the user agent (UA) level or
            above, rather than necessitating modifications to existing
            mail protocols or 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.  No mechanisms
            are assumed to prevent users from sending, at their
            discretion, messages to which no PEM processing has been
            applied. 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.

   Based on these principles, the following facilities are provided:

        1.  disclosure protection,

        2.  originator authenticity,

        3.  message integrity measures, and

        4.  (if asymmetric key management is used) non-repudiation of
            origin,

   but the following privacy-relevant concerns are not addressed:

        1.  access control,




Linn                                                            [Page 5]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


        2.  traffic flow confidentiality,