rfc2633.txt

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

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

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 non-security
   part of 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.



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


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







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


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.

     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=20 because 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 CMS 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.



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


   The carried CMS object always contains a MIME entity that is prepared
   as described in section 3.1 if the eContentType is id-data. Other
   contents may be carried when the eContentType contains different
   values. See [ESS] for an example of this with signed receipts.

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

   Note that this discussion refers to the transfer encoding of the CMS
   object or "outside" MIME entity. It is completely distinct from, and
   unrelated to, the transfer encoding of the MIME entity secured by the
   CMS 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 (signedData,      .p7m
   envelopedData)

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

   Application/pkcs7-signature              .p7s

   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.





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


   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
   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.2.2 The smime-type parameter

   The application/pkcs7-mime content type defines the optional "smime-
   type" parameter. The intent of this parameter is to convey details
   about the security applied (signed or enveloped) along with
   infomation about the contained content. This memo defines the
   following smime-types.

   Name                   Security                Inner Content

   enveloped-data         EnvelopedData           id-data

   signed-data            SignedData              id-data

   certs-only             SignedData              none

   In order that consistency can be obtained with future, the following
   guidelines should be followed when assigning a new smime-type
   parameter.

   1. If both signing and encryption can be applied to the content, then
   two values for smime-type SHOULD be assigned "signed-*" and
   "encrypted-*".  If one operation can be assigned then this may be
   omitted. Thus since "certs-only" can only be signed, "signed-" is
   omitted.

   2. A common string for a content oid should be assigned. We use
   "data" for the id-data content OID when MIME is the inner content.

   3. If no common string is assigned.  Then the common string of
   "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
   would be DES40).




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


3.3 Creating an Enveloped-only Message

   This section describes the format for enveloping a MIME entity
   without signing it. It is important to note that sending enveloped
   but not signed messages does not provide for data integrity. It is
   possible to replace ciphertext in such a way that the processed
   message will still be valid, but the meaning may be altered.

   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
   CMS object of type envelopedData. In addition to encrypting a copy of
   the content-encryption key for each recipient, a copy of the content
   encryption key SHOULD be encrypted for the originator and included in
   the envelopedData (see CMS Section 6).

   Step 3. The CMS 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 with SignedData, and multipart/signed. In
   general, the multipart/signed form is preferred for sending, and
   receiving agents SHOULD be able to handle both.










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


3.4.1 Choosing a Format for Signed-only Messages

   There are no hard-and-fast rules when a particular signed-only format