rfc2633.txt

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

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   The structure of the SMIMECapabilities attribute is to facilitate
   simple table lookups and binary comparisons in order to determine
   matches. For instance, the DER-encoding for the SMIMECapability for
   DES EDE3 CBC MUST be identically encoded regardless of the
   implementation.

   In the case of symmetric algorithms, the associated parameters for
   the OID MUST specify all of the parameters necessary to differentiate
   between two instances of the same algorithm. For instance, the number
   of rounds and block size for RC5 must be specified in addition to the
   key length.

   There is a list of OIDs (OIDs Used with S/MIME) that is centrally
   maintained and is separate from this memo. The list of OIDs is
   maintained by the Internet Mail Consortium at
   <http://www.imc.org/ietf-smime/oids.html>. Note that all OIDs
   associated with the MUST and SHOULD implement algorithms are included
   in section A of this document.

   The OIDs that correspond to algorithms SHOULD use the same OID as the
   actual algorithm, except in the case where the algorithm usage is
   ambiguous from the OID. For instance, in an earlier draft,
   rsaEncryption was ambiguous because it could refer to either a
   signature algorithm or a key encipherment algorithm. In the event
   that an OID is ambiguous, it needs to be arbitrated by the maintainer
   of the registered SMIMECapabilities list as to which type of
   algorithm will use the OID, and a new OID MUST be allocated under the
   smimeCapabilities OID to satisfy the other use of the OID.

   The registered SMIMECapabilities list specifies the parameters for
   OIDs that need them, most notably key lengths in the case of
   variable-length symmetric ciphers. In the event that there are no
   differentiating parameters for a particular OID, the parameters MUST
   be omitted, and MUST NOT be encoded as NULL.

   Additional values for the SMIMECapabilities attribute may be defined
   in the future. Receiving agents MUST handle a SMIMECapabilities
   object that has values that it does not recognize in a graceful
   manner.

2.5.3 Encryption Key Preference Attribute

   The encryption key preference attribute allows the signer to
   unambiguously describe which of the signer's certificates has the
   signer's preferred encryption key. This attribute is designed to
   enhance behavior for interoperating with those clients which use
   separate keys for encryption and signing. This attribute is used to




Ramsdell                    Standards Track                     [Page 7]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   convey to anyone viewing the attribute which of the listed
   certificates should be used for encrypting a session key for future
   encrypted messages.

   If present, the SMIMEEncryptionKeyPreference attribute MUST be a
   SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
   SignedAttributes as a SET OF Attribute. The SignedAttributes in a
   signerInfo MUST NOT include multiple instances of the
   SMIMEEncryptionKeyPreference attribute.  CMS defines the ASN.1 syntax
   for Attribute to include attrValues SET OF AttributeValue. A
   SMIMEEncryptionKeyPreference attribute MUST only include a single
   instance of AttributeValue.  There MUST NOT be zero or multiple
   instances of AttributeValue present in the attrValues SET OF
   AttributeValue.

   The sending agent SHOULD include the referenced certificate in the
   set of certificates included in the signed message if this attribute
   is used.  The certificate may be omitted if it has been previously
   made available to the receiving agent.  Sending agents SHOULD use
   this attribute if the commonly used or preferred encryption
   certificate is not the same as the certificate used to sign the
   message.

   Receiving agents SHOULD store the preference data if the signature on
   the message is valid and the signing time is greater than the
   currently stored value.  (As with the SMIMECapabilities, the clock
   skew should be checked and the data not used if the skew is too
   great.)  Receiving agents SHOULD respect the sender's encryption key
   preference attribute if possible.  This however represents only a
   preference and the receiving agent may use any certificate in
   replying to the sender that is valid.

2.5.3.1 Selection of Recipient Key Management Certificate

   In order to determine the key management certificate to be used when
   sending a future CMS envelopedData message for a particular
   recipient, the following steps SHOULD be followed:

    - If an SMIMEEncryptionKeyPreference attribute is found in a
   signedData object received from the desired recipient, this
   identifies the X.509 certificate that should be used as the X.509
   key management certificate for the recipient.

   - If an SMIMEEncryptionKeyPreference attribute is not found in a
   signedData object received from the desired recipient, the set of
   X.509 certificates should be searched for a X.509 certificate with
   the same subject name as the signing X.509 certificate which can
   be used for key management.



Ramsdell                    Standards Track                     [Page 8]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   - Or use some other method of determining the user's key management
   key. If a X.509 key management certificate is not found, then
   encryption cannot be done with the signer of the message. If multiple
   X.509 key management certificates are found, the S/MIME agent can
   make an arbitrary choice between them.

2.6 SignerIdentifier SignerInfo Type

   S/MIME v3 requires the use of SignerInfo version 1, that is the
   issuerAndSerialNumber CHOICE MUST be used for SignerIdentifier.

2.7 ContentEncryptionAlgorithmIdentifier

   Sending and receiving agents MUST support encryption and decryption
   with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES].
   Receiving agents SHOULD support encryption and decryption using the
   RC2 [RC2] or a compatible algorithm at a key size of 40 bits,
   hereinafter called "RC2/40".

2.7.1 Deciding Which Encryption Method To Use

   When a sending agent creates an encrypted message, it has to decide
   which type of encryption to use. The decision process involves using
   information garnered from the capabilities lists included in messages
   received from the recipient, as well as out-of-band information such
   as private agreements, user preferences, legal restrictions, and so
   on.

   Section 2.5 defines a method by which a sending agent can optionally
   announce, among other things, its decrypting capabilities in its
   order of preference. The following method for processing and
   remembering the encryption capabilities attribute in incoming signed
   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 capabilities list in messages whose
      signature could not be verified, MUST NOT be accepted.



Ramsdell                    Standards Track                     [Page 9]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   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
   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.7.2.1 through 2.7.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.7.1.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.7.1.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.











Ramsdell                    Standards Track                    [Page 10]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


2.7.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME

   If:

    - the sending agent has no knowledge of the encryption capabilities
      of the recipient,
    - and the sending agent has no knowledge of the version of S/MIME
      of the recipient,

   then the sending agent SHOULD use tripleDES because it is a stronger
   algorithm and is required by S/MIME v3. If the sending agent chooses
   not to use tripleDES in this step, it SHOULD use RC2/40.

2.7.2 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.7.3 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 may be able to learn 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 CMS
   objects. Several MIME types as well as several CMS 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 CMS processing facilities which produces a
   CMS object.  The CMS object is then finally wrapped in MIME. The
   Enhanced Security Services for S/MIME [ESS] document provides
   examples of how nested, secured S/MIME messages are formatted.  ESS
   provides an example of how a triple-wrapped S/MIME message is
   formatted using multipart/signed and application/pkcs7-mime for the
   signatures.



Ramsdell                    Standards Track                    [Page 11]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   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].

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 CMS 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




Ramsdell                    Standards Track                    [Page 12]

RFC 2633         S/MIME Version 3 Message Specification        June 1999