rfc2311.txt

RFC 的详细文档！

   [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
   2313, March 1998.

   [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
   1.5", RFC 2315, March 1998.



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


   [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax
   Version 1.5", RFC 2314, March 1998.

   [RC2] Rivest, R., "Description of the RC2(r) Encryption Algorithm",
   RFC 2268, January 1998.

   [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
   Institute of Standards and Technology, U.S. Department of Commerce,
   DRAFT, 31 May 1994.










































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