[CERT3].
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
"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.
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.
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
}
-- 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}
--
-- 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
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", RFC2632, 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", RFC2630,
June 1999.
[CONTDISP] Troost, R., Dorner, S. and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC2183, 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",
RFC2631, June 1999.
[DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18
May 1994.
[ESS] Hoffman, P., Editor "Enhanced Security Services for
S/MIME", RFC2634, 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", RFC2045; "MIME Part 2:
Media Types", RFC2046; "MIME Part 3: Message Header
Extensions for Non-ASCII Text", RFC2047; "MIME Part
4: Registration Procedures", RFC2048; "MIME Part 5:
Conformance Criteria and Examples", RFC2049,
September 1993.
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC1847, October 1995.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC2119, March 1997.
[PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0",
RFC2437, October 1998.
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC2315, March 1998.
[RANDOM] Eastlake, 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC1750,
December 1994.
[RC2] Rivest, R., "A Description of the RC2 (r) Encryption
Algorithm", RFC2268, 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", RFC2311, March 1998.
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 contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they
made direct contributions to this document.
Dave Crocker
Bill Flanigan
Paul Hoffman
Russ Housley
John Pawling
Jim Schaad
Editor's Address
Blake Ramsdell
Worldtalk
17720 NE 65th St Ste 201
Redmond, WA 98052
Phone: +1 425 376 0225
EMail: blaker@deming.com
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.