rfc1113.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            J. Linn
Request for Comments:  1113                                          DEC
Obsoletes RFCs: 989, 1040                         IAB Privacy Task Force
                                                             August 1989


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

STATUS OF THIS MEMO

   This RFC suggests a draft standard elective 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, Curt Barker, Jim Bidzos, Matt Bishop, Danny Cohen, Tom
   Daniel, Charles Fox, Morrie Gasser, Russ Housley, Steve Kent
   (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob
   Shirey, Miles Smid, Steve Walker, and Steve Wilbur.

Table of Contents

   1.  Executive Summary                                               2
   2.  Terminology                                                     3
   3.  Services, Constraints, and Implications                         3
   4.  Processing of Messages                                          7
   4.1  Message Processing Overview                                    7
   4.1.1  Types of Keys                                                7
   4.1.2  Processing Procedures                                        8
   4.2  Encryption Algorithms and Modes                                9
   4.3  Privacy Enhancement Message Transformations                   10
   4.3.1  Constraints                                                 10
   4.3.2  Approach                                                    11
   4.3.2.1  Step 1: Local Form                                        12
   4.3.2.2  Step 2: Canonical Form                                    12
   4.3.2.3  Step 3: Authentication and Encipherment                   12
   4.3.2.4  Step 4: Printable Encoding                                13
   4.3.2.5  Summary of Transformations                                15
   4.4  Encapsulation Mechanism                                       15
   4.5  Mail for Mailing Lists                                        17
   4.6  Summary of Encapsulated Header Fields                         18



Linn                                                            [Page 1]

RFC 1113                Mail Privacy: Procedures             August 1989


   4.6.1  Per-Message Encapsulated Header Fields                      20
   4.6.1.1  X-Proc-Type Field                                         20
   4.6.1.2  X-DEK-Info Field                                          21
   4.6.2  Encapsulated Header Fields Normally Per-Message             21
   4.6.2.1  X-Sender-ID Field                                         22
   4.6.2.2  X-Certificate Field                                       22
   4.6.2.3  X-MIC-Info Field                                          23
   4.6.3  Encapsulated Header Fields with Variable Occurrences        23
   4.6.3.1  X-Issuer-Certificate Field                                23
   4.6.4  Per-Recipient Encapsulated Header Fields                    24
   4.6.4.1  X-Recipient-ID Field                                      24
   4.6.4.2  X-Key-Info Field                                          24
   4.6.4.2.1  Symmetric Key Management                                24
   4.6.4.2.2  Asymmetric Key Management                               25
   5.  Key Management                                                 26
   5.1  Data Encrypting Keys (DEKs)                                   26
   5.2  Interchange Keys (IKs)                                        26
   5.2.1  Subfield Definitions                                        28
   5.2.1.1  Entity Identifier Subfield                                28
   5.2.1.2  Issuing Authority Subfield                                29
   5.2.1.3  Version/Expiration Subfield                               29
   5.2.2  IK Cryptoperiod Issues                                      29
   6.  User Naming                                                    29
   6.1  Current Approach                                              29
   6.2  Issues for Consideration                                      30
   7.  Example User Interface and Implementation                      30
   8.  Areas For Further Study                                        31
   9.  References                                                     32
   NOTES                                                              32

1.  Executive Summary

   This RFC defines message encipherment and authentication procedures,
   in order to provide privacy enhancement services for electronic mail
   transfer in the Internet.  It is one member of a related set of four
   RFCs.  The procedures defined in the current RFC 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-1114 specifies supporting key
   management mechanisms based on the use of public-key certificates.
   RFC-1115 specifies algorithm and related information relevant to the
   current RFC and to RFC-1114.  A subsequent RFC will provide 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, and



Linn                                                            [Page 2]

RFC 1113                Mail Privacy: Procedures             August 1989


   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.

2.  Terminology

   For descriptive purposes, this RFC uses some terms defined in the OSI
   X.400 Message Handling System Model per the 1984 CCITT
   Recommendations.  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 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.

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
   sender and recipient UAs.  No privacy enhancements are offered for
   message fields which are added or transformed by intermediate relay
   points.



Linn                                                            [Page 3]

RFC 1113                Mail Privacy: Procedures             August 1989


   Authentication and integrity facilities are always applied to the
   entirety of a message's text.  No facility for confidentiality
   without authentication is provided.  Encryption facilities may be
   applied selectively to portions of a message's contents; this allows
   less sensitive portions of messages (e.g., descriptive fields) to be
   processed by a recipient's delegate in the absence of the recipient's
   personal cryptographic keys.  In the limiting case, where the
   entirety of message text is excluded from encryption, this feature
   can be used to yield the effective combination of authentication and
   integrity services without confidentiality.

   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 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 are compatible 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 are compatible with a broad range of
          electronic mail user agents (UAs).  A large variety of



Linn                                                            [Page 4]

RFC 1113                Mail Privacy: Procedures             August 1989


          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
          privacy-enhanced 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 (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.  Different key management
          mechanisms may be used for different recipients of a
          multicast message.  While support for a particular key
          management mechanism is not a minimum essential requirement
          for compatibility with this RFC, adoption of the public-key
          certificate approach defined in companion RFC-1114 is
          strongly recommended.

   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