rfc2311.txt

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

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


C. Compatibility with Prior Practice in S/MIME

   S/MIME was originally developed by RSA Data Security, Inc. Many
   developers implemented S/MIME agents before this document was
   published. All S/MIME receiving agents SHOULD make every attempt to
   interoperate with these earlier implementations of S/MIME.

C.1 Early MIME Types

   Some early implementations of S/MIME agents used the following MIME
   types:

   application/x-pkcs7-mime
   application/x-pkcs7-signature
   application/x-pkcs10

   In each case, the "x-" subtypes correspond to the subtypes described
   in this document without the "x-".

C.2 Profiles

   Early S/MIME documentation had two profiles for encryption:
   "restricted" and "unrestricted". The difference between these
   profiles historically came about due to US Government export
   regulations, as described at the end of this section. It is expected
   that in the future, there will be few agents that only use the
   restricted profile.

   Briefly, the restricted profile required the ability to encrypt and
   decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-
   bit keys. The unrestricted profile required the ability to encrypt
   and decrypt using RSA's trade-secret RC2 algorithm in CBC mode with
   40-bit keys, and to encrypt and decrypt using tripleDES. The
   restricted profile also had non-mandatory suggestions for other
   algorithms, but these were not widely implemented.

   It is important to note that many current implementations of S/MIME
   use the restricted profile.

C.2.1 Historical Reasons for the Existence of Two Encryption Profiles

   Due to US Government export regulations, an S/MIME agent which
   supports a strong content encryption algorithm such as DES would not
   be freely exportable outside of North America. US software
   manufacturers have been compelled to incorporate an exportable or
   "restricted" content encryption algorithm in order to create a widely
   exportable version of their product.  S/MIME agents created in the US
   and intended for US domestic use (or use under special State



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


   Department export licenses) can utilize stronger, "unrestricted"
   content encryption. However, in order to achieve interoperability,
   such agents need to support whatever exportable algorithm is
   incorporated in restricted S/MIME agents.

   The RC2 symmetric encryption algorithm has been approved by the US
   Government for "expedited" export licensing at certain key sizes.
   Consequently, support for the RC2 algorithm in CBC mode is required
   for baseline interoperability in all S/MIME implementations. Support
   for other strong symmetric encryption algorithms such as RC5 CBC, DES
   CBC and DES EDE3-CBC for content encryption is strongly encouraged
   where possible.







































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


D. Request for New MIME Subtypes

D.1 application/pkcs7-mime

   To: [e-mail]
   Subject: Registration of MIME media type application/pkcs7-mime

   MIME media type name: application

   MIME subtype name: pkcs7-mime

   Required parameters: none

   Optional parameters: name, filename, smime-type

   Encoding considerations: Will be binary data, therefore should use
   base64 encoding

   Security considerations: Described in [PKCS-7]

   Interoperability considerations: Designed to carry data formatted
   with PKCS-7, as described in [PKCS-7]

   Published specification: RFC 2311

   Applications which use this media type: Secure Internet mail and
   other secure data transports.

   Additional information:
   File extension(s): .p7m and .p7c
   Macintosh File Type Code(s):

   Person & email address to contact for further information:
   Steve Dusse, [e-mail]

   Intended usage: COMMON

D.2 application/pkcs7-signature

   To: [e-mail]
   Subject: Registration of MIME media type application/pkcs7-signature

   MIME media type name: application

   MIME subtype name: pkcs7-signature

   Required parameters: none




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


   Optional parameters: name, filename

   Encoding considerations: Will be binary data, therefore should use
   base64 encoding

   Security considerations: Described in [PKCS-7]

   Interoperability considerations: Designed to carry digital
   signatures with PKCS-7, as described in [PKCS-7]

   Published specification: RFC 2311

   Applications which use this media type: Secure Internet mail and
   other secure data transports.

   Additional information:
   File extension(s): .p7s
   Macintosh File Type Code(s):

   Person & email address to contact for further information:
   Steve Dusse, [e-mail]

   Intended usage: COMMON

D.3 application/pkcs10

   To: [e-mail]
   Subject: Registration of MIME media type application/pkcs10

   MIME media type name: application

   MIME subtype name: pkcs10

   Required parameters: none

   Optional parameters: name, filename

   Encoding considerations: Will be binary data, therefore should use
   base64 encoding

   Security considerations: Described in [PKCS-10]

   Interoperability considerations: Designed to carry digital
   certificates formatted with PKCS-10, as described in [PKCS-10]

   Published specification: RFC 2311

   Applications which use this media type: Secure Internet mail and



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


   other transports where certificates are required.

   Additional information:
   File extension(s): .p10
   Macintosh File Type Code(s):

   Person & email address to contact for further information:
   Steve Dusse, [e-mail]

   Intended usage: COMMON









































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


E. Encapsulating Signed Messages for Internet Transport

   The rationale behind the multiple formats for signing has to do with
   the MIME subtype defaulting rules of the application and multipart
   top-level types, and the behavior of currently deployed gateways and
   mail user agents.

   Ideally, the multipart/signed format would be the only format used
   because it provides a truly backwards compatible way to sign MIME
   entities. In a pure MIME environment with very capable user agents,
   this would be possible. The world, however, is more complex than
   this.

   One problem with the multipart/signed format occurs with gateways to
   non-MIME environments. In these environments, the gateway will
   generally not be S/MIME aware, will not recognize the
   multipart/signed type, and will default its treatment to
   multipart/mixed as is prescribed by the MIME standard. The real
   problem occurs when the gateway also applies conversions to the MIME
   structure of the original message that is being signed and is
   contained in the first part of the multipart/signed structure, such
   as the gateway converting text and attachments to the local format.
   Because the signature is over the MIME structure of the original
   message, but the original message is now decomposed and transformed,
   the signature cannot be verified. Because MIME encoding of a
   particular set of body parts can be done in many different ways,
   there is no way to reconstruct the original MIME entity over which
   the signature was computed.

   A similar problem occurs when an attempt is made to combine an
   existing user agent with a stand-alone S/MIME facility. Typical user
   agents do not have the ability to make a multipart sub-entity
   available to a stand-alone application in the same way they make leaf
   MIME entities available to "viewer" applications. This user agent
   behavior is not required by the MIME standard and thus not widely
   implemented. The result is that it is impossible for most user agents
   to hand off the entire multipart/signed entity to a stand-alone
   application.

E.1