rfc2633.txt

RFC 的详细文档！

   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
   "store and protect" certificates for correspondents in such a way so
   as to guarantee their later retrieval.

4.1 Key Pair Generation

   If an S/MIME agent needs to generate a key pair, then the S/MIME
   agent or some related administrative utility or function MUST be
   capable of generating separate DH and DSS public/private key pairs on
   behalf of the user. Each key pair MUST be generated from a good
   source of non-deterministic random input [RANDOM] and the private key
   MUST be protected in a secure fashion.

   If an S/MIME agent needs to generate a key pair, then the S/MIME
   agent or some related administrative utility or function SHOULD
   generate RSA key pairs.

   A user agent SHOULD generate RSA key pairs at a minimum key size of
   768 bits. A user agent MUST NOT generate RSA key pairs less than 512
   bits long. Creating keys longer than 1024 bits may cause some older
   S/MIME receiving agents to not be able to verify signatures, but
   gives better security and is therefore valuable. A receiving agent
   SHOULD be able to verify signatures with keys of any size over 512
   bits. 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.









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


5. Security

   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.

   If a sending agent is sending the same message using different
   strengths of cryptography, an attacker watching the communications
   channel may be able to 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.

   Modification of the ciphertext can go undetected if authentication is
   not also used, which is the case when sending EnvelopedData without
   wrapping it in SignedData or enclosing SignedData within it.













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


A. ASN.1 Module

SecureMimeMessageV3
  { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
-- Cryptographic Message Syntax
    SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
        FROM    CryptographicMessageSyntax
               { iso(1) member-body(2) us(840) rsadsi(113549)
                 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };

--  id-aa is the arc with all new authenticated and unauthenticated
--  attributes produced the by S/MIME Working Group

id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549)
        pkcs(1) pkcs-9(9) smime(16) attributes(2)}

-- S/MIME Capabilities provides a method of broadcasting the symetric
-- capabilities understood.  Algorithms should be ordered by preference
-- and grouped by type

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

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

SMIMECapabilities ::= SEQUENCE OF SMIMECapability

-- Encryption Key Preference provides a method of broadcasting the
-- preferred encryption certificate.

id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}

SMIMEEncryptionKeyPreference ::= CHOICE {
   issuerAndSerialNumber   [0] IssuerAndSerialNumber,
   receipentKeyId          [1] RecipientKeyIdentifier,
   subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}




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


-- The Content Encryption Algorithms defined for SMIME are:

-- Triple-DES is the manditory algorithm with CBCParameter being the
-- parameters

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

CBCParameter ::= IV

IV ::= OCTET STRING (SIZE (8..8))

--  RC2 (or compatable) is an optional algorithm w/ RC2-CBC-paramter
--  as the parameter

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                   IV}

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

-- The following list the OIDs to be used with S/MIME V3

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

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



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


-- rsa OBJECT IDENTIFIER ::=
--    {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
--
-- id-dsa OBJECT IDENTIFIER ::=
--    {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

-- 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}
--
-- id-dsa-with-sha1 OBJECT IDENTIFIER ::=
--    {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3}

-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
--    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
--    See [CMS] for a description of how to encode the attribute
--    value.

END



















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


B. References

   [3DES]         ANSI X9.52-1998, "Triple Data Encryption Algorithm
                  Modes of Operation", American National Standards
                  Institute, 1998.

   [CERT3]        Ramsdell, B., Editor, "S/MIME Version 3 Certificate
                  Handling", RFC 2632, June 1999.

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

   [CMS]          Housley, R., "Cryptographic Message Syntax", RFC 2630,
                  June 1999.

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

   [DH]           Rescorla, E., "Diffie-Hellman Key Agreement Method",
                  RFC 2631, June 1999.

   [DSS]          NIST FIPS PUB 186, "Digital Signature Standard", 18
                  May 1994.

   [ESS]          Hoffman, P., Editor "Enhanced Security Services for
                  S/MIME", RFC 2634, June 1999.

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

   [MIME-SPEC]    The primary definition of MIME. "MIME Part 1: Format
                  of Internet Message Bodies", RFC 2045; "MIME Part 2:
                  Media Types", RFC 2046; "MIME Part 3: Message Header
                  Extensions for Non-ASCII Text", RFC 2047; "MIME Part
                  4: Registration Procedures", RFC 2048; "MIME Part 5:
                  Conformance Criteria and Examples", RFC 2049,
                  September 1993.

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



Ramsdell                    Standards Track                    [Page 29]