rfc2311.txt

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

   and unrelated to, the transfer encoding of the MIME entity secured by
   the PKCS #7 object, the "inside" object, which is described in
   section 3.1.

   Because there are several types of application/pkcs7-mime objects, a
   sending agent SHOULD do as much as possible to help a receiving agent
   know about the contents of the object without forcing the receiving
   agent to decode the ASN.1 for the object. The MIME headers of all
   application/pkcs7-mime objects SHOULD include the optional "smime-
   type" parameter, as described in the following sections.

3.2.1 The name and filename Parameters

   For the application/pkcs7-mime, sending agents SHOULD emit the
   optional "name" parameter to the Content-Type field for compatibility
   with older systems. Sending agents SHOULD also emit the optional
   Content-Disposition field [CONTDISP] with the "filename" parameter.
   If a sending agent emits the above parameters, the value of the
   parameters SHOULD be a file name with the appropriate extension:

   MIME Type                      File Extension

   application/pkcs7-mime              .p7m
   (signedData, envelopedData)

   application/pkcs7-mime              .p7c
   (degenerate signedData
   "certs-only" message)

   application/pkcs7-signature         .p7s

   application/pkcs10                  .p10

   In addition, the file name SHOULD be limited to eight characters
   followed by a three letter extension. The eight character filename
   base can be any distinct name; the use of the filename base "smime"
   SHOULD be used to indicate that the MIME entity is associated with
   S/MIME.

   Including a file name serves two purposes. It facilitates easier use
   of S/MIME objects as files on disk. It also can convey type
   information across gateways. When a MIME entity of type
   application/pkcs7-mime (for example) arrives at a gateway that has no
   special knowledge of S/MIME, it will default the entity's MIME type
   to application/octet-stream and treat it as a generic attachment,
   thus losing the type information. However, the suggested filename for



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


   an attachment is often carried across a gateway.  This often allows
   the receiving systems to determine the appropriate application to
   hand the attachment off to, in this case a stand-alone S/MIME
   processing application. Note that this mechanism is provided as a
   convenience for implementations in certain environments. A proper
   S/MIME implementation MUST use the MIME types and MUST NOT rely on
   the file extensions.

3.3 Creating an Enveloped-only Message

   This section describes the format for enveloping a MIME entity
   without signing it.

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

     Step 2. The MIME entity and other required data is processed into a
             PKCS #7 object of type envelopedData.

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

   The smime-type parameter for enveloped-only messages is "enveloped-
   data".  The file extension for this type of message is ".p7m".

   A sample message would be:

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

       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       0GhIGfHfQbnj756YT64V

3.4 Creating a Signed-only Message

   There are two formats for signed messages defined for S/MIME:
   application/pkcs7-mime and SignedData, and multipart/signed. In
   general, the multipart/signed form is preferred for sending, and
   receiving agents SHOULD be able to handle both.

3.4.1 Choosing a Format for Signed-only Messages

   There are no hard-and-fast rules when a particular signed-only format
   should be chosen because it depends on the capabilities of all the



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


   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 and 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
             PKCS #7 object of type signedData

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

   The smime-type parameter for messages using application/pkcs7-mime
   and 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

       567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
       77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
       HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
       6YT64V0GhIGfHfQbnj75






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


3.4.3 Signing Using the multipart/signed Format

   This format is a clear-signing format. Recipients without any S/MIME
   or PKCS 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 to be signed; the second part contains the
   signature, which is a PKCS #7 detached signature.

3.4.3.1 The application/pkcs7-signature MIME Type

   This MIME type always contains a single PKCS #7 object of type
   signedData.  The contentInfo field of the PKCS #7 object must be
   empty. The signerInfos field contains the signatures for the MIME
   entity. The details of the registered type are given in Appendix D.

   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 PKCS #7 processing in order
             to obtain an object of type signedData with an empty
             contentInfo field.

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

   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.




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


   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 used in the calculation of
   the Message Integrity Check. The value of the micalg parameter SHOULD
   be one of the following:

   Algorithm used     Value
   --------------     ---------
   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--

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.





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


   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.

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 PKCS #7
             generating process which creates a PKCS #7 object of type
             signedData.  The contentInfo and signerInfos fields must be
             empty.

     Step 2. The PKCS #7 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".

3.7 Creating a Registration Request

   A typical application which allows a user to generate cryptographic
   information has to submit that information to a certification
   authority, who transforms it into a certificate. PKCS #10 describes a
   syntax for certification requests. The application/pkcs10 body type
   MUST be used to transfer a PKCS #10 certification request.

   The details of certification requests and the process of obtaining a
   certificate are beyond the scope of this memo. Instead, only the
   format of data used in application/pkcs10 is defined.

3.7.1 Format of the application/pkcs10 Body

   PKCS #10 defines the ASN.1 type CertificationRequest for use in
   submitting a certification request. Therefore, when the MIME content
   type application/pkcs10 is used, the body MUST be a
   CertificationRequest, encoded using the Basic Encoding Rules (BER).



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


   Although BER is specified, instead of the more restrictive DER, a
   typical application will use DER since the CertificationRequest's
   CertificationRequestInfo has to be DER-encoded in order to be signed.
   A robust application SHOULD output DER, but allow BER or DER on
   input.

   Data produced by BER or DER is 8-bit, but many transports are limited
   to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding
   SHOULD be applied. The base64 Content-Transfer-Encoding SHOULD be
   used with application/pkcs10, although any 7-bit transfer encoding
   may work.

3.7.2 Sending and Receiving an application/pkcs10 Body Part

   For sending a certificate-signing request, the application/pkcs10
   message format MUST be used to convey a PKCS #10 certificate-signing
   request. Note that for sending certificates and CRLs messages without
   any signed content, the application/pkcs7-mime message format MUST be
   used to convey a degenerate PKCS #7 signedData "certs-only" message.

   To send an application/pkcs10 body, the application generates the
   cryptographic information for the user. The details of the
   cryptographic information are beyond the scope of this memo.

     Step 1. The cryptographic information is placed within a PKCS #10
             CertificationRequest.

     Step 2. The CertificationRequest is encoded according to BER or DER
             (typically, DER).

     Step 3. As a typical step, the DER-encoded CertificationRequest is
             also base64 encoded so that it is 7-bit data suitable for
             transfer in SMTP. This then becomes the body of an
             application/pkcs10 body part.