rfc1113.txt

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

                                  Table 1


   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.

4.4  Encapsulation Mechanism

   Encapsulation of privacy-enhanced messages within an enclosing layer



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


   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.

   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.

   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
   copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the
   encapsulated text.

   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



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


   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.

   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-DEK-Info:", "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 enclosing and
           encapsulated header fields such as "Subject:", etc.)

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


                           Message Encapsulation
                                 Figure 1


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-per-
   recipient method.  The choice depends on the information available to



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


   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-per-
   list), 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 asymmetric key management, the
   list's private component 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, 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.

   If, in contrast, a message's sender is equipped to expand the
   destination mailing list into its individual constituents and elects
   to do so (IK-per-recipient), the message's DEK (and, in the symmetric
   key management case, MIC) will be encrypted under each per-recipient
   IK and all such encrypted representations will be incorporated into
   the transmitted message.  Note that per-recipient encryption is
   required only for the relatively small DEK and MIC quantities carried
   in the "X-Key-Info:" field, not for the message text which is, in
   general, much larger.  Although more IKs are involved in processing
   under the IK-per-recipient method, the pairwise IKs can be
   individually revoked and possession of one IK does not enable a
   successful masquerade of another user on the list.

4.6  Summary of Encapsulated Header Fields

   This section summarizes the syntax and semantics of the encapsulated
   header fields to be added to messages in the course of privacy
   enhancement processing.  The fields are presented in three groups.
   Normally, the groups will appear in encapsulated headers in the order
   in which they are shown, though not all fields in each group will
   appear in all messages. In certain indicated cases, it is recommended
   that the fields be replicated within the encapsulated text portion as
   well as being included within the encapsulated header.  Figures 2 and
   3 show the appearance of small example encapsulated messages.  Figure
   2 assumes the use of symmetric cryptography for key management.
   Figure 3 illustrates an example encapsulated message in which
   asymmetric key management is used.

   Unless otherwise specified, all field arguments are processed in a
   case-sensitive fashion.  In most cases, numeric quantities are
   represented in header fields as contiguous strings of hexadecimal
   digits, where each digit is represented by a character from the



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


   ranges "0"-"9" or upper case "A"-"F".  Since public-key certificates
   and quantities encrypted using asymmetric algorithms are large in
   size, use of a more space-efficient encoding technique is appropriate
   for such quantities, and the encoding mechanism defined in Section
   4.3.2.4 of this RFC, representing 6 bits per printed character, is
   adopted.  The example shown in Figure 3 shows asymmetrically
   encrypted quantities (e.g., "X-MIC-Info:", "X-Key-Info:") with 64-
   character printed representations, corresponding to 384 bits.  The
   fields carrying asymmetrically encrypted quantities also illustrate
   the use of folding as defined in RFC-822, section 3.1.1.

   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: [e-mail]::
   X-Recipient-ID: [e-mail]:ptf-kmc:3
   X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD,
    A60195DB94F727D3
   X-Recipient-ID: [e-mail]:ptf-kmc:4
   X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
    9F83A2658132DB47

   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----


               Example Encapsulated Message (Symmetric Case)
                                 Figure 2


   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: [e-mail]::
   X-Certificate:
    jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk
    YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz
    agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0
   X-Issuer-Certificate:
    TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA
    IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX
    vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp
   X-MIC-Info: RSA-MD2,RSA,
    5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz
   X-Recipient-ID: [e-mail]:RSADSI:3



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


   X-Key-Info: RSA,
    lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHU
   X-Recipient-ID: [e-mail]:RSADSI:4
   X-Key-Info: RSA,
    NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh

   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----

              Example Encapsulated Message (Asymmetric Case)
                                 Figure 3


   Although the encapsulated header fields resemble RFC-822 header
   fields, they are a disjoint set and will not in general be processed
   by the same parser which operates on enclosing header fields.  The
   complexity of lexical analysis needed and appropriate for
   encapsulated header field processing is significantly less than that
   appropriate to RFC-822 header processing.  For example, many
   characters with special significance to RFC-822 at the syntactic
   level have no such significance within encapsulated header fields.

   When the length of an encapsulated header field is longer than the
   size conveniently printable on a line, whitespace may be used to fold
   the field in the manner of RFC-822, section 3.1.1.  Any such inserted
   whitespace is not to be interpreted as a part of a subfield.  As a
   particular example, due to the length of public-key certificates and
   of quantities encrypted using asymmetric algorithms, such quantities
   may often need to be folded across multiple printed lines.  In order
   to facilitate such folding in a uniform manner, the bits representing
   such a quantity are to be divided into an ordered set (with leftmost