draft-ietf-smime-cmsalg-07.txt   draft-ietf-smime-cmsalg-08.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
expires in six months December 2001 expires in six months February 2002
Cryptographic Message Syntax (CMS) Algorithms Cryptographic Message Syntax (CMS) Algorithms
<draft-ietf-smime-cmsalg-07.txt> <draft-ietf-smime-cmsalg-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 34 skipping to change at page 1, line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes several cryptographic algorithms for use with This document describes several cryptographic algorithms for use with
the Cryptographic Message Syntax (CMS) [CMS]. The CMS is used to the Cryptographic Message Syntax (CMS) [CMS]. The CMS is used to
digitally sign, digest, authenticate, or encrypt arbitrary messages. digitally sign, digest, authenticate, or encrypt arbitrary message
contents.
This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with
the single word "subscribe" in the body of the message. Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>.
Table of Contents Table of Contents
Status of this Memo .............................................. 1 Status of this Memo .............................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
Table of Contents ................................................ 2 Table of Contents ................................................ 2
1 Introduction ................................................. 3 1 Introduction ................................................. 3
1.1 Changes Since RFC 2630 ................................ 4
1.2 Terminology ........................................... 4
2 Message Digest Algorithms .................................... 3 2 Message Digest Algorithms .................................... 3
2.1 SHA-1 ................................................. 4 2.1 SHA-1 ................................................. 4
2.2 MD5 ................................................... 4 2.2 MD5 ................................................... 4
3 Signature Algorithms ......................................... 4 3 Signature Algorithms ......................................... 4
3.1 DSA ................................................... 5 3.1 DSA ................................................... 5
3.2 RSA ................................................... 6 3.2 RSA ................................................... 6
4 Key Management Algorithms .................................... 7 4 Key Management Algorithms .................................... 7
4.1 Key Agreement Algorithms .............................. 7 4.1 Key Agreement Algorithms .............................. 7
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ........ 8 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ........ 8
4.1.2 X9.42 Static-Static Diffie-Hellman ........... 9 4.1.2 X9.42 Static-Static Diffie-Hellman ........... 9
skipping to change at page 3, line 8 skipping to change at page 3, line 8
7 ASN.1 Module ................................................. 15 7 ASN.1 Module ................................................. 15
8 References ................................................... 19 8 References ................................................... 19
9 Security Considerations ...................................... 20 9 Security Considerations ...................................... 20
10 Acknowledgments .............................................. 23 10 Acknowledgments .............................................. 23
11 Author's Address ............................................. 23 11 Author's Address ............................................. 23
12 Full Copyright Statement ..................................... 23 12 Full Copyright Statement ..................................... 23
1 Introduction 1 Introduction
The Cryptographic Message Syntax (CMS) [CMS] is used to digitally The Cryptographic Message Syntax (CMS) [CMS] is used to digitally
sign, digest, authenticate, or encrypt arbitrary messages. This sign, digest, authenticate, or encrypt arbitrary message contents.
companion specification describes the use of common cryptographic This companion specification describes the use of common
algorithms with the CMS. Implementations of the CMS may support cryptographic algorithms with the CMS. Implementations of the CMS
these algorithms; implementations of the CMS may also support other may support these algorithms; implementations of the CMS may also
algorithms as well. However, if an implementation chooses to support support other algorithms as well. However, if an implementation
one of the algorithms discussed in this document, then the chooses to support one of the algorithms discussed in this document,
implementation MUST do so as described in this document. then the implementation MUST do so as described in this document.
This document obsoletes section 12 of RFC 2630 [OLDCMS]. RFC <TBD>
[CMS] obsoletes the rest of RFC 2630. Separation of the protocol and
algorithm specifications allows each one to be updated without
impacting the other. However, the conventions for using additional
algorithms with the CMS are likely to be specified in separate
documents.
The CMS values are generated using ASN.1 [X.208-88], using BER- The CMS values are generated using ASN.1 [X.208-88], using BER-
encoding [X.209-88]. Algorithm identifiers (which include ASN.1 encoding [X.209-88]. Algorithm identifiers (which include ASN.1
object identifiers) identify cryptographic algorithms, and some object identifiers) identify cryptographic algorithms, and some
algorithms require additional parameters. When needed, parameters algorithms require additional parameters. When needed, parameters
are specified with an ASN.1 structure. The algorithm identifier for are specified with an ASN.1 structure. The algorithm identifier for
each algorithm is specified, and, when needed, the parameter each algorithm is specified, and, when needed, the parameter
structure is specified. The fields in the CMS employed by each structure is specified. The fields in the CMS employed by each
algorithm are identified. algorithm are identified.
1.1 Changes Since RFC 2630
This document obsoletes section 12 of RFC 2630 [OLDCMS]. RFC <TBD>
[CMS] obsoletes the rest of RFC 2630. Separation of the protocol and
algorithm specifications allows each one to be updated without
impacting the other. However, the conventions for using additional
algorithms with the CMS are likely to be specified in separate
documents.
1.2 Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described
by Scott Bradner in [STDWORDS]. by Scott Bradner in [STDWORDS].
2 Message Digest Algorithms 2 Message Digest Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support SHA-1 or MD5. implementations that support SHA-1 or MD5.
Digest algorithm identifiers are located in the SignedData Digest algorithm identifiers are located in the SignedData
skipping to change at page 20, line 44 skipping to change at page 20, line 44
encrypting data, and authenticating data. This document identifies encrypting data, and authenticating data. This document identifies
the conventions for using several cryptographic algorithms for use the conventions for using several cryptographic algorithms for use
with the CMS. with the CMS.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
Implementations must protect the key management private key, the key- Implementations must protect the key management private key, the key-
encryption key, and the content-encryption key. Compromise of the encryption key, and the content-encryption key. Compromise of the
key management private key or the key-encryption key may result in key management private key or the key-encryption key may result in
the disclosure of all messages protected with that key. Similarly, the disclosure of all contents protected with that key. Similarly,
compromise of the content-encryption key may result in disclosure of compromise of the content-encryption key may result in disclosure of
the associated encrypted content. the associated encrypted content.
Implementations must protect the key management private key and the Implementations must protect the key management private key and the
message-authentication key. Compromise of the key management private message-authentication key. Compromise of the key management private
key permits masquerade of authenticated data. Similarly, compromise key permits masquerade of authenticated data. Similarly, compromise
of the message-authentication key may result in undetectable of the message-authentication key may result in undetectable
modification of the authenticated content. modification of the authenticated content.
The key management technique employed to distribute message- The key management technique employed to distribute message-
authentication keys must itself provide authentication, otherwise the authentication keys must itself provide authentication, otherwise the
message content is delivered with integrity from an unknown source. content is delivered with integrity from an unknown source. Neither
Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH-
[DH-X9.42] provide the necessary data origin authentication. Static- X9.42] provide the necessary data origin authentication. Static-
Static Diffie-Hellman [DH-X9.42] does provide the necessary data Static Diffie-Hellman [DH-X9.42] does provide the necessary data
origin authentication when both the originator and recipient public origin authentication when both the originator and recipient public
keys are bound to appropriate identities in X.509 certificates keys are bound to appropriate identities in X.509 certificates
[PROFILE]. [PROFILE].
When more than two parties share the same message-authentication key, When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the message-authentication key can compute a valid MAC, therefore the
message could originate from any one of the parties. content could originate from any one of the parties.
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), one-time message-authentication keys, initialization vectors (IVs), one-time
values (such as the k value when generating a DSA signature), and values (such as the k value when generating a DSA signature), and
padding. Also, the generation of public/private key pairs relies on padding. Also, the generation of public/private key pairs relies on
a random numbers. The use of inadequate pseudo-random number a random numbers. The use of inadequate pseudo-random number
generators (PRNGs) to generate cryptographic such values can result generators (PRNGs) to generate cryptographic such values can result
in little or no security. An attacker may find it much easier to in little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [RANDOM] offers important guidance in numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
PRNG technique. PRNG technique.
When using key agreement algorithms or previously distributed When using key agreement algorithms or previously distributed
symmetric key-encryption keys, a key-encryption key is used to symmetric key-encryption keys, a key-encryption key is used to
encrypt the content-encryption key. If the key-encryption and encrypt the content-encryption key. If the key-encryption and
content-encryption algorithms are different, the effective security content-encryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example, is determined by the weaker of the two algorithms. If, for example,
a message content is encrypted with 168-bit Triple-DES and the content is encrypted with 168-bit Triple-DES and the Triple-DES
Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, content-encryption key is wrapped with a 40-bit RC2 key, then at most
then at most 40 bits of protection is provided. A trivial search to 40 bits of protection is provided. A trivial search to determine the
determine the value of the 40-bit RC2 key can recover Triple-DES key, value of the 40-bit RC2 key can recover Triple-DES key, and then the
and then the Triple-DES key can be used to decrypt the content. Triple-DES key can be used to decrypt the content. Therefore,
Therefore, implementers must ensure that key-encryption algorithms implementers must ensure that key-encryption algorithms are as strong
are as strong or stronger than content-encryption algorithms. or stronger than content-encryption algorithms.
RFC 3217 [WRAP] specifies key wrap algorithms used to encrypt a RFC 3217 [WRAP] specifies key wrap algorithms used to encrypt a
Triple-DES content-encryption key with a Triple-DES key-encryption Triple-DES content-encryption key with a Triple-DES key-encryption
key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key- key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key-
encryption key [RC2]. The key wrap algorithms makes use of CBC mode encryption key [RC2]. The key wrap algorithms makes use of CBC mode
[MODES]. These key wrap algorithms have been reviewed for use with [MODES]. These key wrap algorithms have been reviewed for use with
Triple-DES and RC2. They have not been reviewed for use with other Triple-DES and RC2. They have not been reviewed for use with other
cryptographic modes or other encryption algorithms. Therefore, if a cryptographic modes or other encryption algorithms. Therefore, if a
CMS implementation wishes to support ciphers in addition to Triple- CMS implementation wishes to support ciphers in addition to Triple-
DES or RC2, then additional key wrap algorithms need to be defined to DES or RC2, then additional key wrap algorithms need to be defined to
skipping to change at page 23, line 27 skipping to change at page 23, line 27
Russell Housley Russell Housley
RSA Laboratories RSA Laboratories
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
rhousley@rsasecurity.com rhousley@rsasecurity.com
12 Full Copyright Statement 12 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. In addition, the included on all such copies and derivative works. In addition, the
ASN.1 module presented in Appendix A may be used in whole or in part ASN.1 module presented in Appendix A may be used in whole or in part
without inclusion of the copyright notice. However, this document without inclusion of the copyright notice. However, this document
itself may not be modified in any way, such as by removing the itself may not be modified in any way, such as by removing the
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/