draft-ietf-smime-cmsalg-06.txt   draft-ietf-smime-cmsalg-07.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 September 2001 expires in six months December 2001
Cryptographic Message Syntax (CMS) Algorithms Cryptographic Message Syntax (CMS) Algorithms
<draft-ietf-smime-cmsalg-06.txt> <draft-ietf-smime-cmsalg-07.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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
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]. 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 messages.
This document obsoletes section 12 of RFC 2630. [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.
This draft is being discussed on the "ietf-smime" mailing list. To 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 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 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- is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>. 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
2 Message Digest Algorithms .................................... 3 2 Message Digest Algorithms .................................... 3
2.1 SHA-1 ................................................. 3 2.1 SHA-1 ................................................. 4
2.2 MD5 ................................................... 4 2.2 MD5 ................................................... 4
3 Signature Algorithms ......................................... 4 3 Signature Algorithms ......................................... 4
3.1 DSA ................................................... 4 3.1 DSA ................................................... 5
3.2 RSA ................................................... 5 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 ........ 7 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
4.2 Key Transport Algorithms .............................. 10 4.2 Key Transport Algorithms .............................. 10
4.2.1 RSA (PKCS #1 v1.5) ........................... 10 4.2.1 RSA (PKCS #1 v1.5) ........................... 10
4.3 Symmetric Key-Encryption Key Algorithms ............... 11 4.3 Symmetric Key-Encryption Key Algorithms ............... 11
4.3.1 Triple-DES Key Wrap .......................... 11 4.3.1 Triple-DES Key Wrap .......................... 11
4.3.2 RC2 Key Wrap ................................. 12 4.3.2 RC2 Key Wrap ................................. 12
4.4 Key Derivation Algorithms ............................. 13 4.4 Key Derivation Algorithms ............................. 13
4.4.1 PBKDF2 ....................................... 13 4.4.1 PBKDF2 ....................................... 13
5 Content Encryption Algorithms ................................ 14 5 Content Encryption Algorithms ................................ 14
5.1 Triple-DES CBC ........................................ 14 5.1 Triple-DES CBC ........................................ 14
5.2 RC2 CBC ............................................... 14 5.2 RC2 CBC ............................................... 14
6 Message Authentication Code (MAC) Algorithms ................. 15 6 Message Authentication Code (MAC) Algorithms ................. 15
6.1 HMAC with SHA-1 ....................................... 15 6.1 HMAC with SHA-1 ....................................... 15
Appendix A: ASN.1 Module ........................................ 16 7 ASN.1 Module ................................................. 15
References ....................................................... 19 8 References ................................................... 19
Security Considerations .......................................... 20 9 Security Considerations ...................................... 20
Acknowledgments .................................................. 23 10 Acknowledgments .............................................. 23
Author's Address ................................................. 23 11 Author's Address ............................................. 23
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 messages. This
companion specification lists the common cryptographic algorithms. companion specification describes the use of common cryptographic
Implementations of the CMS MAY support these algorithms; algorithms with the CMS. Implementations of the CMS may support
implementations of the CMS MAY support other algorithms as well. these algorithms; implementations of the CMS may also support other
algorithms as well. However, if an implementation chooses to support
one of the algorithms discussed 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.
skipping to change at page 7, line 25 skipping to change at page 7, line 34
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support key agreement using X9.42 Ephemeral- implementations that support key agreement using X9.42 Ephemeral-
Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie- Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie-
Hellman (X9.42 S-S D-H). Hellman (X9.42 S-S D-H).
When a key agreement algorithm is used, a key-encryption algorithm is When a key agreement algorithm is used, a key-encryption algorithm is
also needed. Therefore, when key agreement is supported, a key- also needed. Therefore, when key agreement is supported, a key-
encryption algorithm MUST be provided for each content-encryption encryption algorithm MUST be provided for each content-encryption
algorithm. The key wrap algorithms for Triple-DES and RC2 are algorithm. The key wrap algorithms for Triple-DES and RC2 are
described in RFC <TBD> [WRAP]. described in RFC 3217 [WRAP].
For key agreement of RC2 key-encryption keys, 128 bits MUST be For key agreement of RC2 key-encryption keys, 128 bits MUST be
generated as input to the key expansion process used to compute the generated as input to the key expansion process used to compute the
RC2 effective key [RC2]. RC2 effective key [RC2].
Key agreement algorithm identifiers are located in the EnvelopedData Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields. keyEncryptionAlgorithm fields.
skipping to change at page 8, line 29 skipping to change at page 8, line 39
key-encryption key is generated when the ephemeral private key key-encryption key is generated when the ephemeral private key
might be used more than once. might be used more than once.
keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
identifier. The algorithm identifier parameter field for id-alg- identifier. The algorithm identifier parameter field for id-alg-
ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key- to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Ephemeral-Static Diffie- encryption key generated using the X9.42 Ephemeral-Static Diffie-
Hellman key agreement algorithm. Triple-DES and RC2 key wrap Hellman key agreement algorithm. Triple-DES and RC2 key wrap
algorithms are described in RFC <TBD> [WRAP]. The id-alg-ESDH algorithms are described in RFC 3217 [WRAP]. The id-alg-ESDH
algorithm identifier and parameter syntax is: algorithm identifier and parameter syntax is:
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 5 } alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
skipping to change at page 9, line 37 skipping to change at page 9, line 44
encryption key is generated for each message between the same encryption key is generated for each message between the same
sender and recipient. sender and recipient.
keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm
identifier. The algorithm identifier parameter field for id-alg- identifier. The algorithm identifier parameter field for id-alg-
SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key- to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Static-Static Diffie- encryption key generated using the X9.42 Static-Static Diffie-
Hellman key agreement algorithm. Triple-DES and RC2 key wrap Hellman key agreement algorithm. Triple-DES and RC2 key wrap
algorithms are described in RFC <TBD> [WRAP]. The id-alg-SSDH algorithms are described in RFC 3217 [WRAP]. The id-alg-SSDH
algorithm identifier and parameter syntax is: algorithm identifier and parameter syntax is:
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 10 } alg(3) 10 }
KeyWrapAlgorithm ::= AlgorithmIdentifier KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key. certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey MUST contain the content- RecipientEncryptedKey EncryptedKey MUST contain the content-
encryption key encrypted with the X9.42 Static-Static Diffie- encryption key encrypted with the X9.42 Static-Static Diffie-
Hellman generated pairwise key-encryption key using the algorithm Hellman generated pairwise key-encryption key using the algorithm
specified by the KeyWrapAlgortihm. specified by the KeyWrapAlgortihm.
4.2 Key Transport Algorithms 4.2 Key Transport Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support key transport using RSA (PKCS #1 v1.5). implementations that support key transport using RSA (PKCS #1 v1.5).
skipping to change at page 10, line 44 skipping to change at page 10, line 50
When using a Triple-DES content-encryption key, CMS implementations When using a Triple-DES content-encryption key, CMS implementations
MUST adjust the parity bits for each DES key comprising the Triple- MUST adjust the parity bits for each DES key comprising the Triple-
DES key prior to RSA encryption. DES key prior to RSA encryption.
The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313
[PKCS#1], to provide confidentiality has a known vulnerability. The [PKCS#1], to provide confidentiality has a known vulnerability. The
vulnerability is primarily relevant to usage in interactive vulnerability is primarily relevant to usage in interactive
applications rather than to store-and-forward environments. Further applications rather than to store-and-forward environments. Further
information and proposed countermeasures are discussed in the information and proposed countermeasures are discussed in the
Security Considerations section of this document and RFC <TBD> [MMA]. Security Considerations section of this document and RFC 3218 [MMA].
Note that the same RSA encryption scheme is also defined in RFC 2437 Note that the same RSA encryption scheme is also defined in RFC 2437
[NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called
RSAES-PKCS1-v1_5. RSAES-PKCS1-v1_5.
4.3 Symmetric Key-Encryption Key Algorithms 4.3 Symmetric Key-Encryption Key Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support symmetric key-encryption key management implementations that support symmetric key-encryption key management
using Triple-DES or RC2 key-encryption keys. When RC2 is supported, using Triple-DES or RC2 key-encryption keys. When RC2 is supported,
skipping to change at page 12, line 4 skipping to change at page 12, line 7
4.3.1 Triple-DES Key Wrap 4.3.1 Triple-DES Key Wrap
A CMS implementation MAY support mixed key-encryption and content- A CMS implementation MAY support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption encryption algorithms. For example, a 128-bit RC2 content-encryption
key MAY be wrapped with 168-bit Triple-DES key-encryption key. key MAY be wrapped with 168-bit Triple-DES key-encryption key.
Triple-DES key encryption has the algorithm identifier: Triple-DES key encryption has the algorithm identifier:
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field MUST be NULL. The AlgorithmIdentifier parameter field MUST be NULL.
The key wrap algorithm used to encrypt a Triple-DES content- The key wrap algorithm used to encrypt a Triple-DES content-
encryption key with a Triple-DES key-encryption key is specified in encryption key with a Triple-DES key-encryption key is specified in
section 3.1 of RFC <TBD> [WRAP]. The corresponding key unwrap section 3.1 of RFC 3217 [WRAP]. The corresponding key unwrap
algorithm is specified in section 3.2 of RFC <TBD> [WRAP]. algorithm is specified in section 3.2 of RFC 3217 [WRAP].
Out-of-band distribution of the Triple-DES key-encryption key used to Out-of-band distribution of the Triple-DES key-encryption key used to
encrypt the Triple-DES content-encryption key is beyond of the scope encrypt the Triple-DES content-encryption key is beyond of the scope
of this document. of this document.
4.3.2 RC2 Key Wrap 4.3.2 RC2 Key Wrap
A CMS implementation MAY support mixed key-encryption and content- A CMS implementation MAY support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption encryption algorithms. For example, a 128-bit RC2 content-encryption
key MAY be wrapped with 168-bit Triple-DES key-encryption key. key MAY be wrapped with 168-bit Triple-DES key-encryption key.
skipping to change at page 12, line 45 skipping to change at page 12, line 49
256 is encoded in the RC2ParameterVersion. For the effective-key- 256 is encoded in the RC2ParameterVersion. For the effective-key-
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length. and 58 respectively. These values are not simply the RC2 key length.
Note that the value 160 must be encoded as two octets (00 A0), Note that the value 160 must be encoded as two octets (00 A0),
because the one octet (A0) encoding represents a negative number. because the one octet (A0) encoding represents a negative number.
RC2 128-bit keys MUST be used as key-encryption keys, and they MUST RC2 128-bit keys MUST be used as key-encryption keys, and they MUST
be used with the RC2ParameterVersion parameter set to 58. be used with the RC2ParameterVersion parameter set to 58.
The key wrap algorithm used to encrypt a RC2 content-encryption key The key wrap algorithm used to encrypt a RC2 content-encryption key
with a RC2 key-encryption key is specified in section 4.1 of RFC with a RC2 key-encryption key is specified in section 4.1 of RFC 3217
<TBD> [WRAP]. The corresponding key unwrap algorithm is specified [WRAP]. The corresponding key unwrap algorithm is specified 4.2 of
4.2 of RFC <TBD> [WRAP]. RFC 3217 [WRAP].
Out-of-band distribution of the RC2 key-encryption key used to Out-of-band distribution of the RC2 key-encryption key used to
encrypt the RC2 content-encryption key is beyond of the scope of this encrypt the RC2 content-encryption key is beyond of the scope of this
document. document.
4.4 Key Derivation Algorithms 4.4 Key Derivation Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support password-based key management using implementations that support password-based key management using
PBKDF2. PBKDF2.
skipping to change at page 15, line 43 skipping to change at page 15, line 48
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
There are two possible encodings for the HMAC with SHA-1 There are two possible encodings for the HMAC with SHA-1
AlgorithmIdentifier parameters field. The two alternatives arise AlgorithmIdentifier parameters field. The two alternatives arise
from the fact that when the 1988 syntax for AlgorithmIdentifier was from the fact that when the 1988 syntax for AlgorithmIdentifier was
translated into the 1997 syntax the OPTIONAL associated with the translated into the 1997 syntax the OPTIONAL associated with the
AlgorithmIdentifier parameters got lost. Later the OPTIONAL was AlgorithmIdentifier parameters got lost. Later the OPTIONAL was
recovered via a defect report, but by then many people thought that recovered via a defect report, but by then many people thought that
algorithm parameters were mandatory. Because of this history some algorithm parameters were mandatory. Because of this history some
implementations encode parameters as a NULL element and others omit implementations may encode parameters as a NULL element and others
them entirely. CMS implementations that support HMAC with SHA-1 MUST omit them entirely.
handle both an AlgorithmIdentifier parameters field which contains a
NULL and an AlgorithmIdentifier with an absent parameters.
Appendix A: ASN.1 Module The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field MUST contain a NULL. Implementations MUST
accept HMAC with SHA-1 AlgorithmIdentifiers with absent parameters.
Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with
NULL parameters. Implementations SHOULD generate HMAC with SHA-1
AlgorithmIdentifiers with absent parameters.
7 ASN.1 Module
CryptographicMessageSyntaxAlgorithms CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) } pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for use in -- The types and values defined in this module are exported for use in
-- the other ASN.1 modules. Other applications may use them for their -- the other ASN.1 modules. Other applications may use them for their
-- own purposes. -- own purposes.
IMPORTS IMPORTS
-- Directory Authentication Framework (X.509-2000) -- Imports from RFC <TBD> [PROFILE], Appendix A.1
AlgorithmIdentifier AlgorithmIdentifier
FROM AuthenticationFramework { joint-iso-itu-t ds(5) FROM PKIX1Explicit88 { iso(1)
module(1) authenticationFramework(7) 4 } ; identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } ;
-- Algorithm Identifiers -- Algorithm Identifiers
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 } oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 } rsadsi(113549) digestAlgorithm(2) 5 }
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
skipping to change at page 19, line 5 skipping to change at page 19, line 5
salt CHOICE { salt CHOICE {
specified OCTET STRING, specified OCTET STRING,
otherSource AlgorithmIdentifier }, otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX), iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL, keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } } DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
END -- of CryptographicMessageSyntaxAlgorithms END -- of CryptographicMessageSyntaxAlgorithms
References 8 References
3DES American National Standards Institute. ANSI X9.52-1998, 3DES American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation. 1998. Triple Data Encryption Algorithm Modes of Operation. 1998.
CERTALGS Bassham, L., R. Housley, and W. Polk. Algorithms and CERTALGS Bassham, L., R. Housley, and W. Polk. Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and CRL Profile. RFC <TBD>. Infrastructure Certificate and CRL Profile. RFC <TBD>.
<Date>. {draft-ietf-pkix-ipki-pkalgs-03.txt} <Date>. {draft-ietf-pkix-ipki-pkalgs-*.txt}
CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>. CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>.
<Date>. {draft-ietf-smime-rfc2630bis-*.txt} <Date>. {draft-ietf-smime-rfc2630bis-*.txt}
DES American National Standards Institute. ANSI X3.106, DES American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems - Data "American National Standard for Information Systems - Data
Link Encryption". 1983. Link Encryption". 1983.
DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method.
RFC 2631. June 1999. RFC 2631. June 1999.
skipping to change at page 19, line 35 skipping to change at page 19, line 35
DSS National Institute of Standards and Technology. DSS National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication.
RFC 2104. February 1997. RFC 2104. February 1997.
MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321.
April 1992. April 1992.
MMA Rescorla, E. Preventing the Million Message Attack on CMS. MMA Rescorla, E. Preventing the Million Message Attack on CMS.
RFC <TBD>. <Date>. {draft-ietf-smime-pkcs1-*.txt} RFC 3218. December 2001.
MODES National Institute of Standards and Technology. MODES National Institute of Standards and Technology.
FIPS Pub 81: DES Modes of Operation. 2 December 1980. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption,
Version 2.0. RFC 2437. October 1998. Version 2.0. RFC 2437. October 1998.
OLDCMS Housley, R., Cryptographic Message Syntax, RFC 2630,
June 1999.
PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5.
RFC 2313. March 1998. RFC 2313. March 1998.
PKCS#5 Kaliski, B. PKCS #5: Password-Based Cryptography PKCS#5 Kaliski, B. PKCS #5: Password-Based Cryptography
Specification, Version 2.0. RFC 2898. September 2000. Specification, Version 2.0. RFC 2898. September 2000.
PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile. RFC <TBD>. <Date>. Profile. RFC <TBD>. <Date>.
{draft-ietf-pkix-new-part1-*.txt} {draft-ietf-pkix-new-part1-*.txt}
skipping to change at page 20, line 16 skipping to change at page 20, line 22
RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
RFC 2268. March 1998. RFC 2268. March 1998.
SHA1 National Institute of Standards and Technology. SHA1 National Institute of Standards and Technology.
FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate
Requirement Levels. RFC2119. March 1997. Requirement Levels. RFC2119. March 1997.
WRAP Housley, R. Triple-DES and RC2 Key Wrapping. RFC <TBD>. WRAP Housley, R. Triple-DES and RC2 Key Wrapping. RFC 3217.
<Date>. {draft-ietf-smime-key-wrap-*.txt} December 2001.
X.208-88 CCITT. Recommendation X.208: Specification of Abstract X.208-88 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988. Rules for Abstract Syntax Notation One (ASN.1). 1988.
Security Considerations 9 Security Considerations
The CMS provides a method for digitally signing data, digesting data, The CMS provides a method for digitally signing data, digesting data,
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-
skipping to change at page 21, line 42 skipping to change at page 21, line 47
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 a message content is encrypted with 168-bit Triple-DES and the
Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, Triple-DES content-encryption key is wrapped with a 40-bit RC2 key,
then at most 40 bits of protection is provided. A trivial search to then at most 40 bits of protection is provided. A trivial search to
determine the value of the 40-bit RC2 key can recover Triple-DES key, determine the value of the 40-bit RC2 key can recover Triple-DES key,
and then the Triple-DES key can be used to decrypt the content. and then the Triple-DES key can be used to decrypt the content.
Therefore, implementers must ensure that key-encryption algorithms Therefore, implementers must ensure that key-encryption algorithms
are as strong or stronger than content-encryption algorithms. are as strong or stronger than content-encryption algorithms.
RFC <TBD> [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
support the additional ciphers. support the additional ciphers.
skipping to change at page 22, line 44 skipping to change at page 22, line 48
alternative. To resolve the adaptive chosen ciphertext alternative. To resolve the adaptive chosen ciphertext
vulnerability, the PKCS #1 Version 2.0 specifies and recommends use vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
is used to provide confidentiality. Designers of protocols and is used to provide confidentiality. Designers of protocols and
systems employing CMS for interactive environments should either systems employing CMS for interactive environments should either
consider usage of OAEP, or should ensure that information which could consider usage of OAEP, or should ensure that information which could
reveal the success or failure of attempted PKCS #1 Version 1.5 reveal the success or failure of attempted PKCS #1 Version 1.5
decryption operations is not provided. Support for OAEP will likely decryption operations is not provided. Support for OAEP will likely
be added to a future version of the CMS algorithm specification. be added to a future version of the CMS algorithm specification.
See RFC <TBD> [MMA] for more information about thwarting the adaptive See RFC 3218 [MMA] for more information about thwarting the adaptive
chosen ciphertext vulnerability in PKCS #1 Version 1.5 chosen ciphertext vulnerability in PKCS #1 Version 1.5
implementations. implementations.
Acknowledgments 10 Acknowledgments
This document is the result of contributions from many professionals. This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson,
Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman,
Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt
Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau,
Jim Schaad, and Dave Solo for their efforts and support. Jim Schaad, and Dave Solo for their efforts and support.
Author Address 11 Author Address
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
Full Copyright Statement 12 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). 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
 End of changes. 

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