rfc1113.txt

RFC 的详细文档！

   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).




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


      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:

      1.  disclosure protection,

      2.  sender 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,

      2.  traffic flow confidentiality,

      3.  address list accuracy,

      4.  routing control,

      5.  issues relating to the casual serial reuse of PCs by
          multiple users,

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

      7.  automatic association of acknowledgments with the messages
          to which they refer, and

      8.  message duplicate detection, replay prevention, or other



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


          stream-oriented services.

   A message's sender will determine whether privacy enhancements are to
   be performed on a particular message.  Therefore, a sender must be
   able to determine whether particular recipients are equipped to
   process privacy-enhanced mail.  In a general architecture, these
   mechanisms will be based on server queries; thus, the query function
   could be integrated into a UA to avoid imposing burdens or
   inconvenience on electronic mail users.

4.  Processing of Messages

4.1  Message Processing Overview

   This subsection provides a high-level overview of the components and
   processing steps involved in electronic mail privacy enhancement
   processing.  Subsequent subsections will define the procedures in
   more detail.

4.1.1  Types of Keys

   A two-level keying hierarchy is used to support privacy-enhanced
   message transmission:

      1.  Data Encrypting Keys (DEKs) are used for encryption of
          message text and (with certain choices among a set of
          alternative algorithms) for computation of message integrity
          check (MIC) quantities.  DEKs are generated individually for
          each transmitted message; no predistribution of DEKs is
          needed to support privacy-enhanced message transmission.

      2.  Interchange Keys (IKs) are used to encrypt DEKs for
          transmission within messages.  Ordinarily, the same IK will
          be used for all messages sent from a given originator to a
          given recipient over a period of time.  Each transmitted
          message includes a representation of the DEK(s) used for
          message encryption and/or MIC computation, encrypted under
          an individual IK per named recipient.  The representation is
          associated with "X-Sender-ID:" and "X-Recipient-ID:" fields,
          which allow each individual recipient to identify the IK
          used to encrypt DEKs and/or MICs for that recipient's use.
          Given an appropriate IK, a recipient can decrypt the
          corresponding transmitted DEK representation, yielding the
          DEK required for message text decryption and/or MIC
          verification.  The definition of an IK differs depending on
          whether symmetric or asymmetric cryptography is used for DEK
          encryption:




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


         2a. When symmetric cryptography is used for DEK
             encryption, an IK is a single symmetric key shared
             between an originator and a recipient.  In this
             case, the same IK is used to encrypt MICs as well
             as DEKs for transmission.  Version/expiration
             information and IA identification associated with
             the originator and with the recipient must be
             concatenated in order to fully qualify a symmetric
             IK.

         2b. When asymmetric cryptography is used, the IK
             component used for DEK encryption is the public
             component of the recipient.  The IK component used
             for MIC encryption is the private component of the
             originator, and therefore only one encrypted MIC
             representation need be included per message, rather than
             one per recipient.  Each of these IK
             components can be fully qualified in an
             "X-Recipient-ID:" or "X-Sender-ID:" field,
             respectively.

4.1.2  Processing Procedures

   When privacy enhancement processing is to be performed on an outgoing
   message, a DEK is generated [1] for use in message encryption and (if
   a chosen MIC algorithm requires a key) a variant of the DEK is formed
   for use in MIC computation.  DEK generation can be omitted for the
   case of a message in which all contents are excluded from encryption,
   unless a chosen MIC computation algorithm requires a DEK.

   An "X-Sender-ID:" field is included in the header to provide one
   identification component for the IK(s) used for message processing.
   IK components are selected for each individually named recipient; a
   corresponding "X-Recipient-ID:" field, interpreted in the context of
   a prior "X-Sender-ID:" field, serves to identify each IK.  Each "X-
   Recipient-ID:" field is followed by an "X-Key-Info:" field, which
   transfers a DEK encrypted under the IK appropriate for the specified
   recipient.  When symmetric key management is used for a given
   recipient, the "X-Key-Info:" field also transfers the message's
   computed MIC, encrypted under the recipient's IK.  When asymmetric
   key management is used, a prior "X-MIC-Info:" field carries the
   message's MIC encrypted under the private component of the sender.

   A four-phase transformation procedure is employed in order to
   represent encrypted message text in a universally transmissible form
   and to enable messages encrypted on one type of host computer to be
   decrypted on a different type of host computer.  A plaintext message
   is accepted in local form, using the host's native character set and



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


   line representation.  The local form is converted to a canonical
   message text representation, defined as equivalent to the inter-SMTP
   representation of message text.  This canonical representation forms
   the input to the MIC computation and encryption processes.

   For encryption purposes, the canonical representation is padded as
   required by the encryption algorithm.  The padded canonical
   representation is encrypted (except for any regions which are
   explicitly excluded from encryption).  The encrypted text (along with
   the canonical representation of regions which were excluded from
   encryption) is encoded into a printable form.  The printable form is
   composed of a restricted character set which is chosen to be
   universally representable across sites, and which will not be
   disrupted by processing within and between MTS entities.

   The output of the encoding procedure is combined with a set of header
   fields carrying cryptographic control information.  The result is
   passed to the electronic mail system to be encapsulated as the text
   portion of a transmitted message.

   When a privacy-enhanced message is received, the cryptographic
   control fields within its text portion provide the information
   required for the authorized recipient to perform MIC verification and
   decryption of the received message text.  First, the printable
   encoding is converted to a bitstring.  Encrypted portions of the
   transmitted message are decrypted.  The MIC is verified.  The
   canonical representation is converted to the recipient's local form,
   which need not be the same as the sender's local form.

4.2  Encryption Algorithms and Modes

   For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined
   in ANSI X3.92-1981 [2] shall be used for encryption of message text.
   The DEA-1 is equivalent to the Data Encryption Standard (DES), as
   defined in FIPS PUB 46 [3].  When used for encryption of text, the
   DEA-1 shall be used in the Cipher Block Chaining (CBC) mode, as
   defined in ISO IS 8372 [4].  The identifier string "DES-CBC", defined
   in RFC-1115, signifies this algorithm/mode combination.  The CBC mode
   definition in IS 8372 is equivalent to that provided in FIPS PUB 81
   [5] and in ANSI X3.106-1983 [16].  Use of other algorithms and/or
   modes for message text processing will require case-by-case study to
   determine applicability and constraints.  Additional algorithms and
   modes approved for use in this context will be specified in
   successors to RFC-1115.

   It is an originator's responsibility to generate a new pseudorandom
   initializing vector (IV) for each privacy-enhanced electronic mail
   message unless the entirety of the message is excluded from



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


   encryption.  Section 4.3.1 of [17] provides rationale for this
   requirement, even in a context where individual DEKs are generated
   for individual messages.  The IV will be transmitted with the
   message.

   Certain operations require that one key be encrypted under an
   interchange key (IK) for purposes of transmission.  A header facility
   indicates the mode in which the IK is used for encryption.  RFC-1115
   specifies encryption algorithm/mode identifiers, including DES-ECB,
   DES-EDE, and RSA.  All implementations using symmetric key management
   should support DES-ECB IK use, and all implementations using
   asymmetric key management should support RSA IK use.

   RFC-1114, released concurrently with this RFC, specifies asymmetric,
   certificate-based key management procedures to support the message
   processing procedures defined in this document.  The message
   processing procedures can also be used with symmetric key management,
   given prior distribution of suitable symmetric IKs through out-of-
   band means.  Support for the asymmetric approach defined in RFC-1114
   is strongly recommended.

4.3  Privacy Enhancement Message Transformations

4.3.1  Constraints

   An electronic mail encryption mechanism must be compatible with the
   transparency constraints of its underlying electronic mail
   facilities.  These constraints are generally established based on
   expected user requirements and on the characteristics of anticipated
   endpoint and transport facilities.  An encryption mechanism must also
   be compatible with the local conventions of the computer systems
   which it interconnects.  In our approach, a canonicalization step is