rfc989.txt

RFC 相关的技术文档

               text's length to be precisely the same as the input
               message's length.  A final 3-octet input quantum will be
               represented as a 4 octet encoding with no terminal "=", a
               2-octet input quantum will be represented as 3 octets
               followed by one terminal "=", and a 1-octet input quantum
               will be represented as 2 octets followed by two
               occurrences of "=".

   A sender may exclude one or more portions of a message from
   encryption/authentication processing.  Explicit action is required to
   exclude a portion of a message from such processing; by default,
   encryption/authentication 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/authentication processing.  An
   excluded area is represented in the inter-SMTP transmission form
   (universal across communicating systems) by bracketing with the
   reserved delimiter "*".  Cryptographic state is preserved
   transparently across an excluded area and continued after the end of
   the excluded area.  A printable encoding quantum (per step 4b) is
   completed before the delimiter "*" is output to initiate or terminate
   the representation of an excluded block.  Note that the
   canonicalizing transformation (step 2 above) and the encoding to
   printable form (step 4 above) are applied to all portions of message
   text, even those excluded from encryption and authentication.

   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, Privacy Task Force                                       [Page 10]

RFC 989                                                    February 1987


        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/authentication
        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.  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 RFC934 [8] 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.  Note that, while encryption and/or authentication
   processing of transmitted mail may depend on information contained in
   the enclosing header (e.g., "To:"), 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



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


   processing can be applied recursively.

   Sensitive data should be 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.  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.  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 the "Subject:" field, it is recommended that the
   enclosing header contain a "Subject:" field indicating that
   "Encrypted Mail Follows".

   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  Processing for Authentication Without Confidentiality

   When a message is to be authenticated without confidentiality
   service, a DEK is generated [9] for use in MAC computation, and a MAC
   is computed using that DEK.  For each individually identified
   recipient, an IK is selected and identified with an "X-IK-ID:" field.
   Each "X-IK-ID:" field is followed by an "X-Key-Info:" field which
   transfers the key under which MAC computation was performed,
   encrypted under the IK identified by the preceding "X-IK-ID:" field,
   along with a representation of the MAC encrypted under the same IK.
   The encapsulated text portion following the encapsulated header is
   canonically encoded, and coded into printable characters for
   transmission, but not encrypted.
















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


   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-IK-ID:", "X-Key-Info:",
           and "X-Pad-Count:".  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

4.6  Processing for Authentication and Confidentiality

   When a message is to be authenticated with confidentiality service, a
   DEK is generated for use in MAC computation and a variant of the DEK
   is formed for use in message encryption.  For each individually
   identified recipient, an IK is selected and identified with an "X-
   IK-ID:" field.  Each "X-IK-ID:" field is followed by an "X-Key-Info:"
   field, which transfers the DEK and computed MAC, each encrypted under
   the IK identified in the preceding "X-IK-ID:" field.  The
   encapsulated text portion following the encapsulated header is
   canonically encoded, encrypted, and coded into printable characters



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


   for transmission.

4.7  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
   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.  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 MAC 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 MAC 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.8  Summary of Added Header and Control Fields

   This section summarizes the syntax and semantics of the new header
   and control fields to be added to messages in the course of privacy
   enhancement processing, indicating whether a particular field occurs
   in a message's encapsulated header portion or its encapsulated text
   portion.  Figure 2 shows the appearance of a small example
   encapsulated message using these fields.  In all cases, hexadecimal
   quantities are represented as contiguous strings of digits, where
   each digit is represented by a character from the ranges "0"-"9" or
   upper case "A"-"F".  Unless otherwise specified, all arguments are to
   be processed in a case-sensitive fashion.