rfc1421.txt

RFC 的详细文档！

   is inappropriate to forward directly to a third party a message that
   is ENCRYPTED because recipients of such a message would not have
   access to the DEK required to decrypt the message.  Instead, the user
   forwarding the message must transform the ENCRYPTED message into a
   MIC-ONLY or MIC-CLEAR form prior to forwarding.  Thus, in order to
   comply with this RFC, a PEM implementation must provide a facility to
   enable a user to perform this transformation, while preserving the
   MIC associated with the original message.

   If a user wishes PEM-provided confidentiality protection for
   transmitted information, such information must occur in the
   encapsulated text of an ENCRYPTED PEM message, not in the enclosing
   MTS header or PEM encapsulated header. If a user wishes to avoid























Linn                                                           [Page 16]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   Encapsulated Message

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

       Encapsulated Header Portion
           (Contains encryption control fields inserted in plaintext.
           Examples include "DEK-Info:" and "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
           Encapsulated Text Portion)

       Encapsulated Text Portion
           (Contains message data encoded as specified in Section 4.3.)

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


                   Encapsulated Message Format
                            Figure 1


   disclosing the actual subject of a message to unintended parties, it
   is suggested that the enclosing MTS header contain a "Subject:" field
   indicating that "Encrypted Mail Follows".

   If an integrity-protected representation of information which occurs
   within an enclosing header (not necessarily in the same format as
   that in which it occurs within that header) is desired, that data can
   be included within the encapsulated text portion in addition to its
   inclusion in the enclosing MTS header.  For example, an originator
   wishing to provide recipients with a protected indication of a
   message's position in a series of messages could include within the
   encapsulated text a copy of a timestamp or message counter value
   possessing end-to-end significance and extracted from an enclosing
   MTS header field.  (Note: mailbox specifiers as entered by end users
   incorporate local conventions and are subject to modification at
   intermediaries, so inclusion of such specifiers within encapsulated
   text should not be regarded as a suitable alternative to the
   authentication semantics defined in RFC 1422 and based on X.500
   Distinguished Names.) The set of header information (if any) included
   within the encapsulated text of messages is a local matter, and this



Linn                                                           [Page 17]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   RFC does not specify formatting conventions to distinguish replicated
   header fields from other encapsulated text.

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.  Hybrid approaches are also possible, as in the
   case of IK-per-list protection of a message on its path from an
   originator to a PEM-equipped mailing list exploder, followed by IK-
   per-recipient protection from the exploder to individual list
   recipients.

   If a message's originator is equipped to expand a 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 "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.

   If a message's originator 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. 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 originator to
   the list for authentication purposes.

   Pure IK-per-list key management in the asymmetric case (with a common
   private key shared among multiple list members) is particularly
   disadvantageous in the asymmetric environment, as it fails to
   preserve the forwardable authentication and non-repudiation
   characteristics which are provided for other messages in this
   environment.  Use of a hybrid approach with a PEM-capable exploder is
   therefore particularly recommended for protection of mailing list
   traffic when asymmetric key management is used; such an exploder
   would reduce (per discussion in Section 4.4 of this RFC) incoming
   ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding
   them (perhaps re-encrypted under individual, per-recipient keys) to
   list members.



Linn                                                           [Page 18]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


4.6  Summary of Encapsulated Header Fields

   This section defines 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.  The
   following figures 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 ENCRYPTED
   message in which asymmetric key management is used.


   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,ENCRYPTED
   Content-Domain: RFC822
   DEK-Info: DES-CBC,F8143EDE5960C597
   Originator-ID-Symmetric: [e-mail],,
   Recipient-ID-Symmetric: [e-mail],ptf-kmc,3
   Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
             B70665BB9BF7CBCDA60195DB94F727D3
   Recipient-ID-Symmetric: [e-mail],ptf-kmc,4
   Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
             E2EF532C65CBCFF79F83A2658132DB47

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

          Example Encapsulated Message (Symmetric Case)
                            Figure 2


   Figure 4 illustrates an example encapsulated MIC-ONLY message in
   which asymmetric key management is used; since no per-recipient keys
   are involved in preparation of asymmetric-case MIC-ONLY messages,
   this example should be processable for test purposes by arbitrary PEM
   implementations.

   Fully-qualified domain names (FQDNs) for hosts, appearing in the
   mailbox names found in entity identifier subfields of "Originator-
   ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in
   a case-insensitive fashion.  Unless specified to the contrary, other
   field arguments (including the user name components of mailbox names)



Linn                                                           [Page 19]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   are to be 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 ranges "0"-"9" or upper case
   "A"-"F".  Since public-key certificates and quantities encrypted













































Linn                                                           [Page 20]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,ENCRYPTED
   Content-Domain: RFC822
   DEK-Info: DES-CBC,BFF968AA74691AC1
   Originator-Certificate:
    MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
    BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
    CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
    MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
    yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
    LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
    iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
    5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
   Key-Info: RSA,
    I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
    wGrtiUm/ovtKdinz6ZQ/aQ==
   Issuer-Certificate:
    MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
    BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
    CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN