rfc2633.txt

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

   should be chosen because it depends on the capabilities of all the
   receivers and the relative importance of receivers with S/MIME
   facilities being able to verify the signature versus the importance
   of receivers without S/MIME software being able to view the message.

   Messages signed using the multipart/signed format can always be
   viewed by the receiver whether they have S/MIME software or not. They
   can also be viewed whether they are using a MIME-native user agent or
   they have messages translated by a gateway. In this context, "be
   viewed" means the ability to process the message essentially as if it
   were not a signed message, including any other MIME structure the
   message might have.

   Messages signed using the signedData format cannot be viewed by a
   recipient unless they have S/MIME facilities. However, if they have
   S/MIME facilities, these messages can always be verified if they were
   not changed in transit.

3.4.2 Signing Using application/pkcs7-mime with SignedData

   This signing format uses the application/pkcs7-mime MIME type. The
   steps to create this format are:

   Step 1. The MIME entity is prepared according to section 3.1

   Step 2. The MIME entity and other required data is processed into a
   CMS object of type signedData

   Step 3. The CMS object is inserted into an application/pkcs7-mime
   MIME entity

   The smime-type parameter for messages using application/pkcs7-mime
   with SignedData is "signed-data". The file extension for this type of
   message is ".p7m".

   A sample message would be:

       Content-Type: application/pkcs7-mime; smime-type=signed-data;
            name=smime.p7m
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7m







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


       567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
       77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
       HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
       6YT64V0GhIGfHfQbnj75

3.4.3 Signing Using the multipart/signed Format

   This format is a clear-signing format. Recipients without any S/MIME
   or CMS processing facilities are able to view the message. It makes
   use of the multipart/signed MIME type described in [MIME-SECURE]. The
   multipart/signed MIME type has two parts. The first part contains the
   MIME entity that is signed; the second part contains the "detached
   signature" CMS SignedData object in which the encapContentInfo
   eContent field is absent.

3.4.3.1 The application/pkcs7-signature MIME Type

   This MIME type always contains a single CMS object of type
   signedData.  The signedData encapContentInfo eContent field MUST be
   absent. The signerInfos field contains the signatures for the MIME
   entity.

   The file extension for signed-only messages using application/pkcs7-
   signature is ".p7s".

3.4.3.2 Creating a multipart/signed Message

   Step 1. The MIME entity to be signed is prepared according to section
   3.1, taking special care for clear-signing.

   Step 2. The MIME entity is presented to CMS processing in order to
   obtain an object of type signedData in which the encapContentInfo
   eContent field is absent.

   Step 3. The MIME entity is inserted into the first part of a
   multipart/signed message with no processing other than that described
   in section 3.1.

   Step 4. Transfer encoding is applied to the "detached signature" CMS
   SignedData object and it is inserted into a MIME entity of type
   application/pkcs7-signature.

   Step 5. The MIME entity of the application/pkcs7-signature is
   inserted into the second part of the multipart/signed entity.

   The multipart/signed Content type has two required parameters: the
   protocol parameter and the micalg parameter.




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


   The protocol parameter MUST be "application/pkcs7-signature". Note
   that quotation marks are required around the protocol parameter
   because MIME requires that the "/" character in the parameter value
   MUST be quoted.

   The micalg parameter allows for one-pass processing when the
   signature is being verified. The value of the micalg parameter is
   dependent on the message digest algorithm(s) used in the calculation
   of the Message Integrity Check. If multiple message digest algorithms
   are used they MUST be separated by commas per [MIME-SECURE]. The
   values to be placed in the micalg parameter SHOULD be from the
   following:

   Algorithm   Value
   used

   MD5         md5
   SHA-1       sha1
   Any other   unknown

   (Historical note: some early implementations of S/MIME emitted and
   expected "rsa-md5" and "rsa-sha1" for the micalg parameter.)
   Receiving agents SHOULD be able to recover gracefully from a micalg
   parameter value that they do not recognize.

3.4.3.3 Sample multipart/signed Message

       Content-Type: multipart/signed;
          protocol="application/pkcs7-signature";
          micalg=sha1; boundary=boundary42

       --boundary42
       Content-Type: text/plain

       This is a clear-signed message.

       --boundary42
       Content-Type: application/pkcs7-signature; name=smime.p7s
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7s

       ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
       4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
       n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       7GhIGfHfYT64VQbnj756

       --boundary42--




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


3.5 Signing and Encrypting

   To achieve signing and enveloping, any of the signed-only and
   encrypted-only formats may be nested. This is allowed because the
   above formats are all MIME entities, and because they all secure MIME
   entities.

   An S/MIME implementation MUST be able to receive and process
   arbitrarily nested S/MIME within reasonable resource limits of the
   recipient computer.

   It is possible to either sign a message first, or to envelope the
   message first. It is up to the implementor and the user to choose.
   When signing first, the signatories are then securely obscured by the
   enveloping. When enveloping first the signatories are exposed, but it
   is possible to verify signatures without removing the enveloping.
   This may be useful in an environment were automatic signature
   verification is desired, as no private key material is required to
   verify a signature.

   There are security ramifications to choosing whether to sign first or
   encrypt first. A recipient of a message that is encrypted and then
   signed can validate that the encrypted block was unaltered, but
   cannot determine any relationship between the signer and the
   unencrypted contents of the message. A recipient of a message that is
   signed-then-encrypted can assume that the signed message itself has
   not been altered, but that a careful attacker may have changed the
   unauthenticated portions of the encrypted message.

3.6 Creating a Certificates-only Message

   The certificates only message or MIME entity is used to transport
   certificates, such as in response to a registration request. This
   format can also be used to convey CRLs.

   Step 1. The certificates are made available to the CMS generating
   process which creates a CMS object of type signedData. The signedData
   encapContentInfo eContent field MUST be absent and signerInfos field
   MUST be empty.

   Step 2. The CMS signedData object is enclosed in an
   application/pkcs7-mime MIME entity

   The smime-type parameter for a certs-only message is "certs-only".
   The file extension for this type of message is ".p7c".






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


3.7 Registration Requests

   A sending agent that signs messages MUST have a certificate for the
   signature so that a receiving agent can verify the signature. There
   are many ways of getting certificates, such as through an exchange
   with a certificate authority, through a hardware token or diskette,
   and so on.

   S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
   with certificate authorities using an application/pkcs10 body part.
   The IETF's PKIX Working Group is preparing another method for
   requesting certificates; however, that work was not finished at the
   time of this memo. S/MIME v3 does not specify how to request a

   certificate, but instead mandates that every sending agent already
   has a certificate. Standardization of certificate management is being
   pursued separately in the IETF.

3.8 Identifying an S/MIME Message

   Because S/MIME takes into account interoperation in non-MIME
   environments, several different mechanisms are employed to carry the
   type information, and it becomes a bit difficult to identify S/MIME
   messages. The following table lists criteria for determining whether
   or not a message is an S/MIME message. A message is considered an
   S/MIME message if it matches any below.

   The file suffix in the table below comes from the "name" parameter in
   the content-type header, or the "filename" parameter on the content-
   disposition header. These parameters that give the file suffix are
   not listed below as part of the parameter section.

   MIME type:   application/pkcs7-mime
   parameters:  any
   file suffix: any

   MIME type:   multipart/signed
   parameters:  protocol="application/pkcs7-signature"
   file suffix: any

   MIME type:   application/octet-stream
   parameters:  any
   file suffix: p7m, p7s, p7c








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


4. Certificate Processing

   A receiving agent MUST provide some certificate retrieval mechanism
   in order to gain access to certificates for recipients of digital
   envelopes. This memo does not cover how S/MIME agents handle
   certificates, only what they do after a certificate has been
   validated or rejected. S/MIME certification issues are covered in
   [CERT3].

   At a minimum, for initial S/MIME deployment, a user agent could
   automatically generate a message to an intended recipient requesting
   that recipient's certificate in a signed return message. Receiving
   and sending agents SHOULD also provide a mechanism to allow a user to
   "store and protect" certificates for correspondents in such a way so
   as to guarantee their later retrieval.

4.1 Key Pair Generation

   If an S/MIME agent needs to generate a key pair, then the S/MIME
   agent or some related administrative utility or function MUST be
   capable of generating separate DH and DSS public/private key pairs on
   behalf of the user. Each key pair MUST be generated from a good
   source of non-deterministic random input [RANDOM] and the private key
   MUST be protected in a secure fashion.

   If an S/MIME agent needs to generate a key pair, then the S/MIME
   agent or some related administrative utility or function SHOULD
   generate RSA key pairs.

   A user agent SHOULD generate RSA key pairs at a minimum key size of
   768 bits. A user agent MUST NOT generate RSA key pairs less than 512
   bits long. Creating keys longer than 1024 bits may cause some older
   S/MIME receiving agents to not be able to verify signatures, but
   gives better security and is therefore valuable. A receiving agent
   SHOULD be able to verify signatures with keys of any size over 512
   bits. Some agents created in the United States have chosen to create
   512 bit keys in order to get more advantageous export licenses.
   However, 512 bit keys are considered by many to be cryptographically
   insecure.  Implementors should be aware that multiple (active) key
   pairs may be associated with a single individual. For example, one
   key pair may be used to support confidentiality, while a different
   key pair may be used for authentication.









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


5. Security

   This entire memo discusses security. Security issues not covered in
   other parts of the memo include:

   40-bit encryption is considered weak by most cryptographers. Using