rfc1040.txt

RFC 的详细文档！

Linn                                                            [Page 5]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


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.

   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 quantities (MICs).  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.  An IK may be a single
           symmetric cryptographic key or, where asymmetric
           (public-key) cryptography is used to encrypt DEKs, the
           composition of a public component used by an originator and
           a secret component used by a recipient.  Ordinarily, the
           same IK will be used for all messages sent between a given
           originator-recipient pair over a period of time.  Each
           transmitted message includes a representation of the DEK(s)
           used for message encryption and/or authentication,
           encrypted under an individual IK per named recipient.  This
           representation is associated with sender and recipient
           identification header fields, which enable recipients to
           identify the IKs used.  With this information, the recipient
           can decrypt the transmitted DEK representation, yielding
           the DEK required for message text decryption and/or MIC
           verification.

   When privacy enhancement processing is to be performed on an outgoing
   message, a DEK is generated [1] for use in message encryption and a
   variant of the DEK is formed (if the chosen MIC algorithm requires a
   key) for use in MIC computation.  An "X-Sender-ID:" field is included
   in the header to provide one identification component for the IK(s)
   used for message processing.  An IK is selected for each individually
   identified 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 the DEK and computed MIC.  The
   DEK and MIC are encrypted for transmission under the appropriate IK.



Linn                                                            [Page 6]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   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 system to be
   decrypted on a different type.  A plaintext message is accepted in
   local form, using the host's native character set and 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 encryption and MIC computation 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 explicitly
   excluded from encryption).  The canonically encoded representation is
   encoded, after encryption, 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.  The MIC is verified.
   Encrypted portions of the transmitted message are decrypted, and 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 ISO draft international standard DIS 8227 [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 DIS 8372 [4].  The CBC mode
   definition in DIS 8372 is equivalent to that provided in FIPS PUB 81
   [5].  A unique initializing vector (IV) will be generated for and
   transmitted with each privacy-enhanced electronic mail message.







Linn                                                            [Page 7]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   An algorithm other than DEA-1 may be employed, provided that it
   satisfies the following requirements:

           1.  It must be a 64-bit block cipher, enciphering and
               deciphering in 8-octet blocks.

           2.  It is usable in the ECB and CBC modes defined in DIS
               8372.

           3.  It is able to be keyed using the procedures and
               parameters defined in this RFC.

           4.  It is appropriate for MIC computation, if the selected
               MIC computation algorithm is eCcryption-based.

           5.  Cryptographic key field lengths are limited to 16 octets
               in length.

   Certain operations require that one key be encrypted under another
   key (interchange key) for purposes of transmission.  This encryption
   may be performed using symmetric cryptography by using DEA-1 in
   Electronic Codebook (ECB) mode.  A header facility is available to
   indicate that an associated key is to be used for encryption in
   another mode (e.g., the Encrypt-Decrypt-Encrypt (EDE) mode used for
   key encryption and decryption with pairs of 64-bit keys, as described
   by ASC X3T1 [6], or public-key algorithms).

   Support of public key algorithms for key encryption is under active
   consideration, and it is intended that the procedures defined in this
   RFC be appropriate to allow such usage.  Support of key encryption
   modes other than ECB is optional for implementations, however.
   Therefore, in support of universal interoperability, interchange key
   providers should not specify other modes in the absence of a priori
   information indicating that recipients are equipped to perform key
   encryption in other modes.

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 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
   performed to abstract out local conventions and a subsequent encoding



Linn                                                            [Page 8]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   step is performed to conform to the characteristics of the underlying
   mail transport medium (SMTP).  The encoding conforms to SMTP
   constraints, established to support interpersonal messaging.  SMTP's
   rules are also used independently in the canonicalization process.
   RFC-821's [7] Section 4.5 details SMTP's transparency constraints.

   To encode a message for SMTP transmission, the following requirements
   must be met:

           1.  All characters must be members of the 7-bit ASCII
               character set.

           2.  Text lines, delimited by the character pair <CR><LF>,
               must be no more than 1000 characters long.

           3.  Since the string <CR><LF>.<CR><LF> indicates the end of a
               message, it must not occur in text prior to the end of a
               message.

   Although SMTP specifies a standard representation for line delimiters
   (ASCII <CR><LF>), numerous systems use a different native
   representation to delimit lines.  For example, the <CR><LF> sequences
   delimiting lines in mail inbound to UNIX(tm) systems are transformed
   to single <LF>s as mail is written into local mailbox files.  Lines
   in mail incoming to record-oriented systems (such as VAX VMS) may be
   converted to appropriate records by the destination SMTP [8] server.
   As a result, if the encryption process generated <CR>s or <LF>s,
   those characters might not be accessible to a recipient UA program at
   a destination which uses different line delimiting conventions.  It
   is also possible that conversion between tabs and spaces may be
   performed in the course of mapping between inter-SMTP and local
   format; this is a matter of local option.  If such transformations
   changed the form of transmitted ciphertext, decryption would fail to
   regenerate the transmitted plaintext, and a transmitted MIC would
   fail to compare with that computed at the destination.

   The conversion performed by an SMTP server at a system with EBCDIC as
   a native character set has even more severe impact, since the
   conversion from EBCDIC into ASCII is an information-losing
   transformation.  In principle, the transformation function mapping
   between inter-SMTP canonical ASCII message representation and local
   format could be moved from the SMTP server up to the UA, given a
   means to direct that the SMTP server should no longer perform that
   transformation.  This approach has a major disadvantage: internal
   file (e.g., mailbox) formats would be incompatible with the native
   forms used on the systems where they reside.  Further, it would
   require modification to SMTP servers, as mail would be passed to SMTP
   in a different representation than it is passed at present.



Linn                                                            [Page 9]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


4.3.2  Approach

   Our approach to supporting privacy-enhanced mail across an
   environment in which intermediate conversions may occur encodes mail
   in a fashion which is uniformly representable across the set of
   privacy-enhanced UAs regardless of their systems' native character
   sets.  This encoded form is used to represent mail text from sender
   to recipient, but the encoding is not applied to enclosing mail
   transport headers or to encapsulated headers inserted to carry
   control information between privacy-enhanced UAs.  The encoding's
   characteristics are such that the transformations anticipated between
   sender and recipient UAs will not prevent an encoded message from
   being decoded properly at its destination.

   A sender may exclude one or more portions of a message from
   encryption processing.  Authentication processing is always applied
   to the entirety of message text.  Explicit action is required to
   exclude a portion of a message from encryption processing; by
   default, encryption is applied to the entirety of message text.  The
   user-level delimiter which specifies such exclusion is a local
   matter, and hence may vary between sender and recipient, but all
   systems should provide a means for unambiguous identification of
   areas excluded from encryption processing.

   An outbound privacy-enhanced message undergoes four transformation
   steps, described in the following four subsections.

4.3.2.1  Step 1: Local Form

   The message text is created in the system's native character set,
   with lines delimited in accordance with local convention.

4.3.2.2  Step 2: Canonical Form

   The entire message text, including both those portions subject to
   encipherment processing and those portions excluded from such
   processing, is converted to the universal canonical form,
   equivalent to the inter-SMTP representation [9] as defined in
   RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line
   delimiters).  The processing required to perform this conversion is
   minimal on systems whose native character set is ASCII.  Since a
   message is converted to a standard character set and representation
   before encryption, it can be decrypted and its MIC can be verified
   at any destination system before any conversion necessary to