rfc1421.txt

中、英文RFC文档大全打包下载完全版 .

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


   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 for this
   purpose.

   Encapsulated headers of PEM messages are folded using whitespace per
   RFC 822 header folding conventions; no PEM-specific conventions are
   defined for encapsulated header folding.  The example shown in Figure
   4 shows (in its "MIC-Info:" field) an asymmetrically encrypted
   quantity in its printably encoded representation, illustrating the
   use of RFC 822 folding.

   In contrast to the encapsulated header representations defined in RFC
   1113 and its precursors, the field identifiers adopted in this RFC do
   not begin with the prefix "X-" (for example, the field previously
   denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes
   are not to be emitted by implementations conformant to this RFC.  To
   simplify transition and interoperability with earlier
   implementations, it is suggested that implementations based on this
   RFC accept incoming encapsulated header fields carrying the "X-"
   prefix and act on such fields as if the "X-" were not present.





























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


   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,MIC-ONLY
   Content-Domain: RFC822
   Originator-Certificate:
    MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
    BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
    CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
    MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
    yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
    LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
    iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
    5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
   Issuer-Certificate:
    MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
    BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
    CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
    BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
    XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
    cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
    MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
    dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
    EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
   MIC-Info: RSA-MD5,RSA,
    jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6
    EtE7K2QDeVMCyXsdJlA8fA==

   LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg
   YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo=
   -----END PRIVACY-ENHANCED MESSAGE-----

     Example Encapsulated MIC-ONLY Message (Asymmetric Case)
                            Figure 4


4.6.1  Per-Message Encapsulated Header Fields

   This group of encapsulated header fields contains fields which occur
   no more than once in a PEM message, generally preceding all other
   encapsulated header fields.

4.6.1.1  Proc-Type Field

   The "Proc-Type:" encapsulated header field, required for all PEM
   messages, identifies the type of processing performed on the
   transmitted message.  Only one "Proc-Type:" field occurs in a
   message; the "Proc-Type:" field must be the first encapsulated header



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


   field in the message.

   The "Proc-Type:" field has two subfields, separated by a comma.  The
   first subfield is a decimal number which is used to distinguish among
   incompatible encapsulated header field interpretations which may
   arise as changes are made to this standard.  Messages processed
   according to this RFC will carry the subfield value "4" to
   distinguish them from messages processed in accordance with prior PEM
   RFCs.  The second subfield assumes one of a set of string values,
   defined in the following subsections.

4.6.1.1.1  ENCRYPTED

   The "ENCRYPTED" specifier signifies that confidentiality,
   authentication, integrity, and (given use of asymmetric key
   management) non-repudiation of origin security services have been
   applied to a PEM message's encapsulated text.  ENCRYPTED messages
   require a "DEK-Info:" field and individual Recipient-ID and "Key-
   Info:" fields for all message recipients.

4.6.1.1.2  MIC-ONLY

   The "MIC-ONLY" specifier signifies that all of the security services
   specified for ENCRYPTED messages, with the exception of
   confidentiality, have been applied to a PEM message's encapsulated
   text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC)
   to protect their encapsulated text against modifications at message
   transfer or relay points.

   Specification of MIC-ONLY, when applied in conjunction with certain
   combinations of key management and MIC algorithm options, permits
   certain fields which are superfluous in the absence of encryption to
   be omitted from the encapsulated header.  In particular, when a
   keyless MIC computation is employed for recipients for whom
   asymmetric cryptography is used, "Recipient-ID-Asymmetric:" and
   "Key-Info:" fields can be omitted.  The "DEK-Info:" field can be
   omitted for all "MIC-ONLY" messages.

4.6.1.1.3  MIC-CLEAR

   The "MIC-CLEAR" specifier represents a PEM message with the same
   security service selection as for a MIC-ONLY message.  The set of
   encapsulated header fields required in a MIC-CLEAR message is the
   same as that required for a MIC-ONLY message.

   MIC-CLEAR message processing omits the encoding step defined in
   Section 4.3.2.4 of this RFC to protect a message's encapsulated text
   against modifications within the MTS.  As a result, a MIC-CLEAR



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


   message's text can be read by recipients lacking access to PEM
   software, even though such recipients cannot validate the message's
   signature. The canonical encoding discussed in Section 4.3.2.2 is
   performed, so interoperation among sites with different native
   character sets and line representations is not precluded so long as
   those native formats are unambiguously translatable to and from the
   canonical form.  (Such interoperability is feasible only for those
   characters which are included in the canonical representation set.)

   Omission of the printable encoding step implies that MIC-CLEAR
   message MICs will be validatable only in environments where the MTS
   does not modify messages in transit, or where the modifications
   performed can be determined and inverted before MIC validation
   processing.  Failed MIC validation on a MIC-CLEAR message does not,
   therefore, necessarily signify a security-relevant event; as a
   result, it is recommended that PEM implementations reflect to their
   users (in a suitable local fashion) the type of PEM message being
   processed when reporting a MIC validation failure.

   A case of particular relevance arises for inbound SMTP processing on
   systems which delimit text lines with local native representations
   other than the SMTP-conventional <CR><LF>.  When mail is delivered to
   a UA on such a system and presented for PEM processing, the <CR><LF>
   has already been translated to local form.  In order to validate a
   MIC-CLEAR message's MIC in this situation, the PEM module must
   recanonicalize the incoming message in order to determine the inter-
   SMTP representation of the canonically encoded message (as defined in
   Section 4.3.2.2 of this RFC), and must compute the reference MIC
   based on that representation.

4.6.1.1.4  CRL

   The "CRL" specifier indicates a special PEM message type, used to
   transfer one or more Certificate Revocation Lists.  The format of PEM
   CRLs is defined in RFC 1422.  No user data or encapsulated text
   accompanies an encapsulated header specifying the CRL message type; a
   correctly-formed CRL message's PEM header is immediately followed by
   its terminating message boundary line, with no blank line
   intervening.

   Only three types of fields are valid in the encapsulated header
   comprising a CRL message.  The "CRL:" field carries a printable
   representation of a CRL, encoded using the procedures defined in
   Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be
   followed by no more than one "Originator-Certificate:" field and any
   number of "Issuer-Certificate:" fields. The "Originator-Certificate:"
   and "Issuer-Certificate:" fields refer to the most recently previous
   "CRL:" field, and provide certificates useful in validating the



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


   signature included in the CRL.  "Originator-Certificate:" and
   "Issuer-Certificate:" fields' contents are the same for CRL messages
   as they are for other PEM message types.

4.6.1.2  Content-Domain Field

   The "Content-Domain:" encapsulated header field describes the type of
   content which is represented within a PEM message's encapsulated
   text.  It carries one string argument, whose value is defined as
   "RFC822" to indicate processing of RFC-822 mail as defined in this
   specification.  It is anticipated that additional "Content-Domain:"
   values will be defined subsequently, in additional or successor
   documents to this specification. Only one "Content-Domain:" field
   occurs in a PEM message; this field is the PEM message's second
   encapsulated header field, immediately following the "Proc-Type:"
   field.

4.6.1.3  DEK-Info Field

   The "DEK-Info:" encapsulated header field identifies the message text
   encryption algorithm and mode, and also carries any cryptographic
   parameters (e.g., IVs) used for message encryption.  No more than one
   "DEK-Info:" field occurs in a message; the field is required for all
   messages specified as "ENCRYPTED" in the "Proc-Type:" field.

   The "DEK-Info:" field carries either one argument or two arguments
   separated by a comma.  The first argument identifies the algorithm
   and mode used for message text encryption.  The second argument, if
   present, carries any cryptographic parameters required by the
   algorithm and mode identified in the first argument.  Appropriate
   message encryption algorithms, modes and identifiers and
   corresponding cryptographic parameters and formats are defined in RFC
   1423.

4.6.2  Encapsulated Header Fields Normally Per-Message

   This group of encapsulated header fields contains fields which
   ordinarily occur no more than once per message.  Depending on the key
   management option(s) employed, some of these fields may be absent
   from some messages.

4.6.2.1  Originator-ID Fields

   Originator-ID encapsulated header fields identify a message's
   originator and provide the originator's IK identification component.
   Two varieties of Originator-ID fields are defined, the "Originator-
   ID-Asymmetric:" and "Originator-ID-Symmetric:" field.  An
   "Originator-ID-Symmetric:" header field is required for all PEM



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


   messages employing symmetric key management.  The analogous
   "Originator-ID-Asymmetric:" field, for the asymmetric key management
   case, is used only when no corresponding "Originator-Certificate:"
   field is included.

   Most commonly, only one Originator