rfc1113.txt

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

      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.




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


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

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.




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


   A sender may exclude one or more portions of a message from
   encryption processing, but 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 a universal canonical form, analogous 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.  (Note: Since the output of the
   canonical encoding process will never be submitted directly to SMTP,
   but only to subsequent steps of the privacy enhancement encoding
   process, the dot-stuffing transformation discussed in RFC-821,
   section 4.5.2, is not required.)  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 type of destination
   host computer.  The decryption and MIC verification is performed
   before any conversions which may be necessary to transform the
   message into a destination-specific local form.

4.3.2.3  Step 3: Authentication and Encipherment

   The canonical form is input to the selected MIC computation algorithm
   in order to compute an integrity check quantity for the message.  No
   padding is added to the canonical form before submission to the MIC
   computation algorithm, although certain MIC algorithms will apply
   their own padding in the course of computing a MIC.

   Padding is applied to the canonical form as needed to perform
   encryption in the DEA-1 CBC mode, as follows: The number of octets to
   be encrypted is determined by subtracting the number of octets



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


   excluded from encryption from the total length of the canonically
   encoded text.  Octets with the hexadecimal value FF (all ones) are
   appended to the canonical form as needed so that the text octets to
   be encrypted, along with the added padding octets, fill an integral
   number of 8-octet encryption quanta.  No padding is applied if the
   number of octets to be encrypted is already an integral multiple of
   8.  The use of hexadecimal FF (a value outside the 7-bit ASCII set)
   as a padding value allows padding octets to be distinguished from
   valid data without inclusion of an explicit padding count indicator.

   The regions of the message which have not been excluded from
   encryption are encrypted.  To support selective encipherment
   processing, an implementation must retain internal indications of the
   positions of excluded areas excluded from encryption with relation to
   non-excluded areas, so that those areas can be properly delimited in
   the encoding procedure defined in step 4.  If a region excluded from
   encryption intervenes between encrypted regions, cryptographic state
   (e.g., IVs and accumulation of octets into encryption quanta) is
   preserved and continued after the excluded region.

4.3.2.4  Step 4: Printable Encoding

   Proceeding from left to right, the bit string resulting from step 3
   is 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).  This
   encoding step is performed for all privacy-enhanced messages, even if
   an entire message is excluded from encryption.

   A 64-character subset of International Alphabet IA5 is used, 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 character "=" is used for padding within
   the printable encoding procedure.  The character "*" is used to
   delimit the beginning and end of a region which has been excluded
   from encipherment processing.  The encoding function's output is
   delimited into text lines (using local conventions), with each line
   except the last containing exactly 64 printable characters and the
   final line containing 64 or fewer printable characters.  (This line
   length is easily printable and is guaranteed to satisfy SMTP's 1000-
   character transmitted line length limit.)

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters. Proceeding from left to right across
   a 24-bit input group extracted from the output of step 3, each 6-bit



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


   group 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 0, are selected so as to be
   universally representable, and the set excludes characters with
   particular significance to SMTP (e.g., ".", "<CR>", "<LF>").

   Special processing is performed if fewer than 24 bits are available
   in an input group, either at the end of a message or (when the
   selective encryption facility is invoked) at the end of an encrypted
   region or an excluded region.  A full encoding quantum is always
   completed at the end of a message and before the delimiter "*" is
   output to initiate or terminate the representation of a block
   excluded from encryption.  When fewer than 24 input bits are
   available in an input group, 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 the
   character "=".  Since all canonically encoded output is an integral
   number of octets, only the following cases can arise: (1) the final
   quantum of encoding input is an integral multiple of 24 bits; here,
   the final unit of encoded output will be an integral multiple of 4
   characters with no "=" padding, (2) the final quantum of encoding
   input is exactly 8 bits; here, the final unit of encoded output will
   be two characters followed by two "=" padding characters, or (3) the
   final quantum of encoding input is exactly 16 bits; here, the final
   unit of encoded output will be three characters followed by one "="
   padding character.

























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


4.3.2.5  Summary of Transformations

   In summary, the outbound message is subjected to the following
   composition of transformations:

        Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))

   The inverse transformations are performed, in reverse order, to
   process inbound privacy-enhanced mail:


       Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))

   Value Encoding  Value Encoding  Value Encoding  Value Encoding
       0 A            17 R            34 i            51 z
       1 B            18 S            35 j            52 0
       2 C            19 T            36 k            53 1
       3 D            20 U            37 l            54 2
       4 E            21 V            38 m            55 3
       5 F            22 W            39 n            56 4
       6 G            23 X            40 o            57 5
       7 H            24 Y            41 p            58 6
       8 I            25 Z            42 q            59 7
       9 J            26 a            43 r            60 8
      10 K            27 b            44 s            61 9
      11 L            28 c            45 t            62 +
      12 M            29 d            46 u            63 /
      13 N            30 e            47 v
      14 O            31 f            48 w         (pad) =
      15 P            32 g            49 x
      16 Q            33 h            50 y           (1) *

   (1) The character "*" is used to enclose portions of an
   encoded message to which encryption processing has not
   been applied.


                       Printable Encoding Characters