rfc1040.txt

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

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
   excluded from encryption from the total length of the encapsulated
   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

   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.

   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



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


   from encipherment processing.  The encoding function's output is
   delimited into text lines (using local conventions), with each line
   containing 64 printable characters.

   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
   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 1, 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.  In other words, 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.

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

   Note that the local form and the functions to transform messages to
   and from canonical form may vary between the sender and recipient
   systems without loss of information.




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


        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 delimit portions of an encoded
   message to which encryption processing has not been applied.

                       Printable Encoding Characters
                                  Table 1

4.4  Encapsulation Mechanism

   Encapsulation of privacy-enhanced messages within an enclosing layer
   of headers interpreted by the electronic mail transport system offers
   a number of advantages in comparison to a flat approach in which
   certain fields within a single header are encrypted and/or carry
   cryptographic control information.  Encapsulation provides generality
   and segregates fields with user-to-user significance from those
   transformed in transit.  All fields inserted in the course of
   encryption/authentication processing are placed in the encapsulated
   header.  This facilitates compatibility with mail handling programs
   which accept only text, not header fields, from input files or from
   other programs.  Further, privacy enhancement processing can be
   applied recursively.  As far as the MTS is concerned, information
   incorporated into cryptographic authentication or encryption
   processing will reside in a message's text portion, not its header
   portion.









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


   The encapsulation mechanism to be used for privacy-enhanced mail is
   derived from that described in RFC-934 [11] which is, in turn, based
   on precedents in the processing of message digests in the Internet
   community.  To prepare a user message for encrypted or authenticated
   transmission, it will be transformed into the representation shown in
   Figure 1.

   Enclosing Header Portion
           (Contains header fields per RFC-822)

   Blank Line
            (Separates Enclosing Header from Encapsulated Message)

   Encapsulated Message

      Pre-Encapsulation Boundary (Pre-EB)
          -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----

      Encapsulated Header Portion
          (Contains encryption control fields inserted in plaintext.
          Examples include "X-IV:", "X-Sender-ID:", and "X-Key-Info:".
          Note that, although these control fields have line-oriented
          representations similar to RFC-822 header fields, the set of
          fields valid in this context is disjoint from those used in
          RFC-822 processing.)

      Blank Line
          (Separates Encapsulated Header from subsequent encoded
          Encapsulated Text Portion)

      Encapsulated Text Portion
          (Contains message data encoded as specified in Section 4.3;
          may incorporate protected copies of "Subject:", etc.)

      Post-Encapsulation Boundary (Post-EB)
          -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----

                              Message Encapsulation
                                     Figure 1

   As a general design principle, sensitive data is protected by
   incorporating the data within the encapsulated text rather than by
   applying measures selectively to fields in the enclosing header.
   Examples of potentially sensitive header information may include
   fields such as "Subject:", with contents which are significant on an
   end-to-end, inter-user basis.  The (possibly empty) set of headers to
   which protection is to be applied is a user option.  It is strongly
   recommended, however, that all implementations should replicate



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


   copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the
   encapsulated text and include those replicated fields in encryption
   and MIC computations.

   If a user wishes disclosure protection for header fields, they must
   occur only in the encapsulated text and not in the enclosing or
   encapsulated header.  If disclosure protection is desired for a
   message's subject indication, it is recommended that the enclosing
   header contain a "Subject:" field indicating that "Encrypted Mail
   Follows".

   If an authenticated version of header information is desired, that
   data can be replicated within the encapsulated text portion in
   addition to its inclusion in the enclosing header.  For example, a
   sender wishing to provide recipients with a protected indication of a
   message's position in a series of messages could include a copy of a
   timestamp or message counter field within the encapsulated text.

   A specific point regarding the integration of privacy-enhanced mail
   facilities with the message encapsulation mechanism is worthy of
   note.  The subset of IA5 selected for transmission encoding
   intentionally excludes the character "-", so encapsulated text can be
   distinguished unambiguously from a message's closing encapsulation
   boundary (Post-EB) without recourse to character stuffing.

4.5  Mail for Mailing Lists

   When mail is addressed to mailing lists, two different methods of
   processing can be applicable: the IK-per-list method and the IK-
   perrecipient method.  The choice depends on the information available
   to the sender and on the sender's preference.

   If a message's sender addresses a message to a list name or alias,
   use of an IK associated with that name or alias as a entity (IK-
   perlist), rather than resolution of the name or alias to its
   constituent destinations, is implied.  Such an IK must, therefore, be
   available to all list members.  For the case of public-key
   cryptography, the secret component of the composite IK must be
   available to all list members.  This alternative will be the normal
   case for messages sent via remote exploder sites, as a sender to such
   lists may not be cognizant of the set of individual recipients.
   Unfortunately, it implies an undesirable level of exposure for the
   shared IK or component, and makes its revocation difficult.
   Moreover, use of the IK-per-list method allows any holder of the
   list's IK to masquerade as another sender to the list for
   authentication purposes.





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