rfc2311.txt

RFC 的详细文档！

   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.

   The result might look like this:

       Content-Type: application/pkcs10; name=smime.p10
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p10

       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       0GhIGfHfQbnj756YT64V

   A typical application only needs to send a certification request. It
   is a certification authority that has to receive and process the



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


   request. The steps for recovering the CertificationRequest from the
   message are straightforward but are not presented here. The
   procedures for processing the certification request are beyond the
   scope of this document.

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:   application/pkcs10
   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, aps, p7c, p10

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 a
   different document.

   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



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


   "store and protect" certificates for correspondents in such a way so
   as to guarantee their later retrieval.

4.1 Key Pair Generation

   An S/MIME agent or some related administrative utility or function
   MUST be capable of generating RSA key pairs on behalf of the user.
   Each key pair MUST be generated from a good source of non-
   deterministic random input and protected in a secure fashion.

   A user agent SHOULD generate RSA key pairs at a minimum key size of
   768 bits and a maximum key size of 1024 bits. A user agent MUST NOT
   generate RSA key pairs less than 512 bits long. 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.

5. Security Considerations

   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
   weak cryptography in S/MIME offers little actual security over
   sending plaintext. However, other features of S/MIME, such as the
   specification of tripleDES and the ability to announce stronger
   cryptographic capabilities to parties with whom you communicate,
   allow senders to create messages that use strong encryption. Using
   weak cryptography is never recommended unless the only alternative is
   no cryptography. When feasible, sending and receiving agents should
   inform senders and recipients the relative cryptographic strength of
   messages.

   It is impossible for most software or people to estimate the value of
   a message. Further, it is impossible for most software or people to
   estimate the actual cost of decrypting a message that is encrypted
   with a key of a particular size. Further, it is quite difficult to
   determine the cost of a failed decryption if a recipient cannot
   decode a message. Thus, choosing between different key sizes (or
   choosing whether to just use plaintext) is also impossible. However,
   decisions based on these criteria are made all the time, and
   therefore this memo gives a framework for using those estimates in
   choosing algorithms.



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


   If a sending agent is sending the same message using different
   strengths of cryptography, an attacker watching the communications
   channel can determine the contents of the strongly-encrypted message
   by decrypting the weakly-encrypted version. In other words, a sender
   should not send a copy of a message using weaker cryptography than
   they would use for the original of the message.













































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


A. Object Identifiers and Syntax

   The syntax for SMIMECapability is:

   SMIMECapability ::= SEQUENCE {
       capabilityID OBJECT IDENTIFIER,
       parameters OPTIONAL ANY DEFINED BY capabilityID }

   SMIMECapabilities ::= SEQUENCE OF SMIMECapability

A.1 Content Encryption Algorithms

RC2-CBC OBJECT IDENTIFIER ::=
 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2}

For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as:

RC2-CBC parameter ::=  SEQUENCE {
 rc2ParameterVersion  INTEGER,
 iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the
rc2ParameterVersion values are 160, 120, 58 respectively.

DES-EDE3-CBC OBJECT IDENTIFIER ::=
 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7}

For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as:

CBCParameter :: IV

where IV ::= OCTET STRING -- 8 octets.

A.2 Digest Algorithms

md5 OBJECT IDENTIFIER ::=
 {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}

sha-1 OBJECT IDENTIFIER ::=
 {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26}

A.3 Asymmetric Encryption Algorithms

rsaEncryption OBJECT IDENTIFIER ::=
 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}





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


rsa OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}

A.4 Signature Algorithms

md2WithRSAEncryption OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2}

md5WithRSAEncryption OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4}

sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

A.5 Signed Attributes

signingTime OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}

smimeCapabilities OBJECT IDENTIFIER ::=
    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}






























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


B. References

   [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
   IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.

   [CHARSETS] Character sets assigned by IANA. See
   <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>.

   [CONTDISP] Troost, R., Dorner, S and K. Moore, "Communicating
   Presentation Information in Internet Messages:  The Content-
   Disposition Header Field", RFC 2183, August 1997.

   [DES] ANSI X3.106, "American National Standard for Information
   Systems-Data Link Encryption," American National Standards Institute,
   1983.

   [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
   1992.

   [MIME-SPEC] The primary definition of MIME.

   Freed, N., and N. Borenstein, "MIME Part 1: Format of Internet
   Message Bodies", RFC 2045, November 1996.

   Freed, N., and N. Borenstein, "MIME Part 2: Media Types", RFC 2046,
   November 1996.

   Moore, K., "MIME Part 3: Message Header Extensions for Non-ASCII
   Text", RFC 2047, November 1996.

   Freed, N., Klensin, J., and J. Postel, "MIME Part 4: Registration
   Procedures", RFC 2048, November 1996.

   Freed, N., and N. Borenstein, "MIME Part 5: Conformance Criteria and
   Examples", RFC 2049, November 1996.

   [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
   "Security Multiparts for MIME: Multipart/Signed and
   Multipart/Encrypted", RFC 1847, October 1995.

   [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.