rfc2311.txt

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

   messages SHOULD be used.

    - If the receiving agent has not yet created a list of capabilities
      for the sender's public key, then, after verifying the signature
      on the incoming message and checking the timestamp, the receiving
      agent SHOULD create a new list containing at least the signing
      time and the symmetric capabilities.

    - If such a list already exists, the receiving agent SHOULD verify
      that the signing time in the incoming message is greater than the
      signing time stored in the list and that the signature is valid.
      If so, the receiving agent SHOULD update both the signing time and
      capabilities in the list. Values of the signing time that lie far
      in the future (that is, a greater discrepancy than any reasonable
      clock skew), or a capabilitie lists in messages whose signature
      could not be verified, MUST NOT be accepted.

   The list of capabilities SHOULD be stored for future use in creating
   messages.

   Before sending a message, the sending agent MUST decide whether it is
   willing to use weak encryption for the particular data in the



Dusse, et. al.               Informational                      [Page 7]

RFC 2311         S/MIME Version 2 Message Specification       March 1998


   message. If the sending agent decides that weak encryption is
   unacceptable for this data, then the sending agent MUST NOT use a
   weak algorithm such as RC2/40.  The decision to use or not use weak
   encryption overrides any other decision in this section about which
   encryption algorithm to use.

   Sections 2.6.2.1 through 2.6.2.4 describe the decisions a sending
   agent SHOULD use in deciding which type of encryption should be
   applied to a message. These rules are ordered, so the sending agent
   SHOULD make its decision in the order given.

2.6.2.1 Rule 1: Known Capabilities

   If the sending agent has received a set of capabilities from the
   recipient for the message the agent is about to encrypt, then the
   sending agent SHOULD use that information by selecting the first
   capability in the list (that is, the capability most preferred by the
   intended recipient) for which the sending agent knows how to encrypt.
   The sending agent SHOULD use one of the capabilities in the list if
   the agent reasonably expects the recipient to be able to decrypt the
   message.

2.6.2.2 Rule 2: Unknown Capabilities, Known Use of Encryption

   If:
    - the sending agent has no knowledge of the encryption capabilities
      of the recipient,
    - and the sending agent has received at least one message from the
      recipient,
    - and the last encrypted message received from the recipient had a
      trusted signature on it,
   then the outgoing message SHOULD use the same encryption algorithm as
   was used on the last signed and encrypted message received from the
   recipient.

2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption

   If:
    - the sending agent has no knowledge of the encryption capabilities
      of the recipient,
    - and the sending agent is willing to risk that the recipient may
      not be able to decrypt the message,
   then the sending agent SHOULD use tripleDES.








Dusse, et. al.               Informational                      [Page 8]

RFC 2311         S/MIME Version 2 Message Specification       March 1998


2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption

   If:
    - the sending agent has no knowledge of the encryption capabilities
      of the recipient,
    - and the sending agent is not willing to risk that the recipient
      may not be able to decrypt the message,
   then the sending agent MUST use RC2/40.

2.6.3 Choosing Weak Encryption

   Like all algorithms that use 40 bit keys, RC2/40 is considered by
   many to be weak encryption. A sending agent that is controlled by a
   human SHOULD allow a human sender to determine the risks of sending
   data using RC2/40 or a similarly weak encryption algorithm before
   sending the data, and possibly allow the human to use a stronger
   encryption method such as tripleDES.

2.6.4 Multiple Recipients

   If a sending agent is composing an encrypted message to a group of
   recipients where the encryption capabilities of some of the
   recipients do not overlap, the sending agent is forced to send more
   than one message. It should be noted that if the sending agent
   chooses to send a message encrypted with a strong algorithm, and then
   send the same message encrypted with a weak algorithm, someone
   watching the communications channel can decipher the contents of the
   strongly-encrypted message simply by decrypting the weakly-encrypted
   message.

3. Creating S/MIME Messages

   This section describes the S/MIME message formats and how they are
   created.  S/MIME messages are a combination of MIME bodies and PKCS
   objects. Several MIME types as well as several PKCS objects are used.
   The data to be secured is always a canonical MIME entity. The MIME
   entity and other data, such as certificates and algorithm
   identifiers, are given to PKCS processing facilities which produces a
   PKCS object. The PKCS object is then finally wrapped in MIME.

   S/MIME provides one format for enveloped-only data, several formats
   for signed-only data, and several formats for signed and enveloped
   data.  Several formats are required to accommodate several
   environments, in particular for signed messages. The criteria for
   choosing among these formats are also described.

   The reader of this section is expected to understand MIME as
   described in [MIME-SPEC] and [MIME-SECURE].



Dusse, et. al.               Informational                      [Page 9]

RFC 2311         S/MIME Version 2 Message Specification       March 1998


3.1 Preparing the MIME Entity for Signing or Enveloping

   S/MIME is used to secure MIME entities. A MIME entity may be a sub-
   part, sub-parts of a message, or the whole message with all its sub-
   parts. A MIME entity that is the whole message includes only the MIME
   headers and MIME body, and does not include the RFC-822 headers. Note
   that S/MIME can also be used to secure MIME entities used in
   applications other than Internet mail.

   The MIME entity that is secured and described in this section can be
   thought of as the "inside" MIME entity. That is, it is the
   "innermost" object in what is possibly a larger MIME message.
   Processing "outside" MIME entities into PKCS #7 objects is described
   in Section 3.2, 3.4 and elsewhere.

   The procedure for preparing a MIME entity is given in [MIME-SPEC].
   The same procedure is used here with some additional restrictions
   when signing.  Description of the procedures from [MIME-SPEC] are
   repeated here, but the reader should refer to that document for the
   exact procedure. This section also describes additional requirements.

   A single procedure is used for creating MIME entities that are to be
   signed, enveloped, or both signed and enveloped. Some additional
   steps are recommended to defend against known corruptions that can
   occur during mail transport that are of particular importance for
   clear-signing using the multipart/signed format. It is recommended
   that these additional steps be performed on enveloped messages, or
   signed and enveloped messages in order that the message can be
   forwarded to any environment without modification.

   These steps are descriptive rather than prescriptive. The implementor
   is free to use any procedure as long as the result is the same.

     Step 1. The MIME entity is prepared according to the local
             conventions

     Step 2. The leaf parts of the MIME entity are converted to
             canonical form

     Step 3. Appropriate transfer encoding is applied to the leaves of
             the MIME entity

   When an S/MIME message is received, the security services on the
   message are removed, and the result is the MIME entity. That MIME
   entity is typically passed to a MIME-capable user agent where, it is
   further decoded and presented to the user or receiving application.





Dusse, et. al.               Informational                     [Page 10]

RFC 2311         S/MIME Version 2 Message Specification       March 1998


3.1.1 Canonicalization

   Each MIME entity MUST be converted to a canonical form that is
   uniquely and unambiguously representable in the environment where the
   signature is created and the environment where the signature will be
   verified. MIME entities MUST be canonicalized for enveloping as well
   as signing.

   The exact details of canonicalization depend on the actual MIME type
   and subtype of an entity, and are not described here. Instead, the
   standard for the particular MIME type should be consulted. For
   example, canonicalization of type text/plain is different from
   canonicalization of audio/basic. Other than text types, most types
   have only one representation regardless of computing platform or
   environment which can be considered their canonical representation.
   In general, canonicalization will be performed by the sending agent
   rather than the S/MIME implementation.

   The most common and important canonicalization is for text, which is
   often represented differently in different environments. MIME
   entities of major type "text" must have both their line endings and
   character set canonicalized. The line ending must be the pair of
   characters <CR><LF>, and the charset should be a registered charset
   [CHARSETS]. The details of the canonicalization are specified in
   [MIME-SPEC]. The chosen charset SHOULD be named in the charset
   parameter so that the receiving agent can unambiguously determine the
   charset used.

   Note that some charsets such as ISO-2022 have multiple
   representations for the same characters. When preparing such text for
   signing, the canonical representation specified for the charset MUST
   be used.

3.1.2 Transfer Encoding

   When generating any of the secured MIME entities below, except the
   signing using the multipart/signed format, no transfer encoding at
   all is required.  S/MIME implementations MUST be able to deal with
   binary MIME objects. If no Content-Transfer-Encoding header is
   present, the transfer encoding should be considered 7BIT.

   S/MIME implementations SHOULD however use transfer encoding described
   in section 3.1.3 for all MIME entities they secure. The reason for
   securing only 7-bit MIME entities, even for enveloped data that are
   not exposed to the transport, is that it allows the MIME entity to be
   handled in any environment without changing it. For example, a
   trusted gateway might remove the envelope, but not the signature, of
   a message, and then forward the signed message on to the end



Dusse, et. al.               Informational                     [Page 11]

RFC 2311         S/MIME Version 2 Message Specification       March 1998


   recipient so that they can verify the signatures directly. If the
   transport internal to the site is not 8-bit clean, such as on a
   wide-area network with a single mail gateway, verifying the signature
   will not be possible unless the original MIME entity was only 7-bit
   data.

3.1.3 Transfer Encoding for Signing Using multipart/signed

   If a multipart/signed entity is EVER to be transmitted over the
   standard Internet SMTP infrastructure or other transport that is
   constrained to 7-bit text, it MUST have transfer encoding applied so
   that it is represented as 7-bit text. MIME entities that are 7-bit
   data already need no transfer encoding. Entities such as 8-bit text
   and binary data can be encoded with quoted-printable or base-64
   transfer encoding.

   The primary reason for the 7-bit requirement is that the Internet
   mail transport infrastructure cannot guarantee transport of 8-bit or
   binary data. Even though many segments of the transport
   infrastructure now handle 8-bit and even binary data, it is sometimes
   not possible to know whether the transport path is 8-bit clear. If a
   mail message with 8-bit data were to encounter a message transfer
   agent that can not transmit 8-bit or binary data, the agent has three
   options, none of which are acceptable for a clear-signed message:
    - The agent could change the transfer encoding; this would
      invalidate the signature.
    - The agent could transmit the data anyway, which would most likely
      result in the 8th bit being corrupted; this too would invalidate
      the signature.
    - The agent could return the message to the sender.

   [MIME-SECURE] prohibits an agent from changing the transfer encoding
   of the first part of a multipart/signed message. If a compliant agent
   that can not transmit 8-bit or binary data encounters a
   multipart/signed message with 8-bit or binary data in the first part,
   it would have to return the message to the sender as undeliverable.

3.1.4 Sample Canonical MIME Entity

   This example shows a multipart/mixed message with full transfer
   encoding.  This message contains a text part and an attachment. The
   sample message text includes characters that are not US-ASCII and
   thus must be transfer encoded. Though not shown here, the end of each
   line is <CR><LF>. The line ending of the MIME headers, the text, and
   transfer encoded parts, all must be <CR><LF>.

   Note that this example is not of an S/MIME message.




Dusse, et. al.               Informational                     [Page 12]

RFC 2311         S/MIME Version 2 Message Specification       March 1998


       Content-Type: multipart/mixed; boundary=bar

       --bar
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: quoted-printable

       =A1Hola Michael!

       How do you like the new S/MIME specification?

       I agree. It's generally a good idea to encode lines that begin with
       From=20because some mail transport agents will insert a greater-
       than (>) sign, thus invalidating the signature.

       Also, in some cases it might be desirable to encode any   =20
       trailing whitespace that occurs on lines in order to ensure  =20
       that the message signature is not invalidated when passing =20
       a gateway that modifies such whitespace (like BITNET). =20

       --bar
       Content-Type: image/jpeg
       Content-Transfer-Encoding: base64

       iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
       jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
       uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
       HOxEa44b+EI=

       --bar--

3.2 The application/pkcs7-mime Type

   The application/pkcs7-mime type is used to carry PKCS #7 objects of
   several types including envelopedData and signedData. The details of
   constructing these entities is described in subsequent sections. This
   section describes the general characteristics of the
   application/pkcs7-mime type.

   This MIME type always carries a single PKCS #7 object. The PKCS #7
   object must always be BER encoding of the ASN.1 syntax describing the
   object. The contentInfo field of the carried PKCS #7 object always
   contains a MIME entity that is prepared as described in section 3.1.
   The contentInfo field must never be empty.

   Since PKCS #7 objects are binary data, in most cases base-64 transfer
   encoding is appropriate, in particular when used with SMTP transport.
   The transfer encoding used depends on the transport through which the
   object is to be sent, and is not a characteristic of the MIME type.



Dusse, et. al.               Informational                     [Page 13]

RFC 2311         S/MIME Version 2 Message Specification       March 1998


   Note that this discussion refers to the transfer encoding of the PKCS
   #7 object or "outside" MIME entity. It is completely distinct from,