rfc2633.txt

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

   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]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


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

   [PKCS-1]       Kaliski, B., "PKCS #1: RSA Encryption Version 2.0",
                  RFC 2437, October 1998.

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

   [RANDOM]       Eastlake, 3rd, D., Crocker, S. and J. Schiller,
                  "Randomness Recommendations for Security", RFC 1750,
                  December 1994.

   [RC2]          Rivest, R., "A 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, 31May 1994.

   [SMIMEV2]      Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.
                  and L.  Repka, "S/MIME Version 2 Message
                  Specification", RFC 2311, March 1998.




























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


C. Acknowledgements

   Many thanks go out to the other authors of the S/MIME Version 2
   Message Specification RFC:  Steve Dusse, Paul Hoffman, Laurence
   Lundblade and Lisa Repka. Without v2, there wouldn't be a v3.

   A number of the members of the S/MIME Working Group have also worked
   very hard and contrib