rfc989.txt

RFC 相关的技术文档

   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.

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


     1.   Data Encrypting Keys (DEKs) are used for encryption of message



Linn, Privacy Task Force                                        [Page 5]

RFC 989                                                    February 1987


          text and for computation of message authentication codes
          (MACs).  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.  An IK may either be a single symmetric
          cryptographic key or, where asymmetric (public-key)
          cryptography is used for DEK encryption, 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 accompanied by an
          identifier (IK ID) to enable the recipient to determine which
          IK was used, and so to decrypt the representation yielding the
          DEK required for message text decryption and/or MAC
          verification.

   An encoding 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.  Four phases are involved in this process.  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.  The canonical
   representation is padded to an integral multiple of eight octets, as
   required by the encryption algorithm.  MAC computation is performed,
   and (if disclosure protection is required), the padded canonical
   representation is encrypted.  The output of this step 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 (to be defined in Section 4.8) 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 MAC verification and
   decryption on the received message text.  First, the printable
   encoding is converted to a bitstring.  If the transmitted message was
   encrypted, it is decrypted into the canonical representation.  If the
   message was not encrypted, decoding from the printable form produces
   the canonical representation directly.  The MAC is verified, and the



Linn, Privacy Task Force                                        [Page 6]

RFC 989                                                    February 1987


   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 [1] shall be used for
   encryption of message text and for computation of authentication
   codes on messages.  The DEA-1 is equivalent to the Data Encryption
   Standard (DES), as defined in FIPS PUB 46 [2].  When used for these
   purposes, the DEA-1 shall be used in the Cipher Block Chaining (CBC)
   mode, as defined in ISO DIS 8372 [3].  The CBC mode definition in DIS
   8372 is equivalent to that provided in FIPS PUB 81 [4].  A unique
   initializing vector (IV) will be generated for and transmitted with
   each encrypted electronic mail message.

   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 DIS8372

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

       4.  it is appropriate for MAC computation

       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.  For purposes of
   this RFC, such encryption will be performed using DEA-1 in Electronic
   Codebook (ECB) mode.  An optional facility is available to an
   interchange key provider 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 [5] by ASC X3T1).

   Future support of public key algorithms for key encryption is under
   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.





Linn, Privacy Task Force                                        [Page 7]

RFC 989                                                    February 1987


4.3  Canonical Encoding

   Any encryption scheme 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.  SMTP, designed primarily for interpersonal
   messages and anticipating systems and transport media which may be
   restricted to a 7-bit character set, can transmit any 7-bit
   characters (but not arbitrary 8-bit binary data) in message text.

   SMTP introduces other transparency constraints related to line
   lengths and message delimiters.  Message text may not contain the
   string "<CR><LF>.<CR><LF>" in sequence before the end of a message,
   and must contain the string "<CR><LF>" at least every 1000
   characters.  Another important SMTP transparency issue must be noted.
   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 [6] 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 using 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 MAC 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 the disadvantage that it would
   imply internal file (e.g., mailbox) formats which would be
   incompatible with the systems on which they reside, an untenable
   prospect.  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.

   Our approach to this problem selects a canonical character set,
   uniformly representable across privacy-enhanced UAs regardless of
   their systems' native character sets, to transport encrypted mail
   text (but not electronic mail transport headers!) between endpoints.



Linn, Privacy Task Force                                        [Page 8]

RFC 989                                                    February 1987


   In this approach, an outbound privacy-enhanced message is transformed
   between four forms, in sequence:


     1.   (Local_Form) The message text is created (e.g., via an editor)
          in the system's native character set, with lines delimited in
          accordance with local convention.

     2.   (Canonicalize) The message text is converted to the universal
          canonical form, equivalent to the inter-SMTP representation as
          defined in RFC822 [7] (ASCII character set, <CR><LF> line
          delimiters).  (The processing required to perform this
          conversion is relatively small, at least on systems whose
          native character set is ASCII.)

     3.   (Encipher/Authenticate) A padded version of the canonical
          plaintext representation is created by appending zero-valued
          octets to the end of the representation until the length is an
          integral multiple of 8 octets, as is required to perform
          encryption in the DEA-1 CBC mode.  No padding is applied if
          the canonical plaintext representation's length is already a
          multiple of 8 octets.  This padded representation is used as
          the input to the encryption function and to the MAC
          computation function.

     4.   (Encode to Printable Form) The bits resulting from the
          encryption operation are encoded into characters which are
          universally representable at all sites, though not necessarily
          with the same bit patterns (e.g., although the character "E"
          is represented in an ASCII-based system as hexadecimal 45 and
          as hexadecimal C5 in an EBCDIC-based system, the local
          significance of the two representations is equivalent).  Use
          of a 64-character subset of International Alphabet IA5 is
          proposed, enabling 6 bits to be represented per printable
          character.  (The proposed subset of characters is represented
          identically in IA5 and ASCII.) Two additional characters, "="
          and "*", are used to signify special processing functions.
          The encoding function's output is delimited into text lines
          (using local conventions), with each line containing 64
          printable characters.  The encoding process is performed as
          follows, transforming strings of 3 arbitrary (8-bit)
          characters to strings of 4 encoded characters:

          4a.  Proceeding from left to right across the input characters
               (considered as a contiguous bitstring), each group of 6
               bits is used as an index into an array of 64 printable
               characters; the character referenced by the index is
               placed in the output string.  These characters,
               identified in Table 1, are selected so as to be
               universally representable, and the set excludes
               characters with particular significance to SMTP e.g.,



Linn, Privacy Task Force                                        [Page 9]

RFC 989                                                    February 1987


               ".", "<CR>", "<LF>").

          4b.  If fewer than 3 input characters are available in a final
               quantum, zero bits are added (on the right) to form an
               integral number of 6-bit groups.  Output character
               positions which are not required to represent actual
               input data are set to a 65th reserved, universally
               representable character ("=").  Use of a reserved
               character for padding allows compensatory processing to
               be performed by a recipient, allowing the decoded message