draft-ietf-smime-cmsalg-01.txt   draft-ietf-smime-cmsalg-02.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 July 2001 expires in six months August 2001
Cryptographic Message Syntax (CMS) Algorithms Cryptographic Message Syntax (CMS) Algorithms
<draft-ietf-smime-cmsalg-01.txt> <draft-ietf-smime-cmsalg-02.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 38 skipping to change at page 1, line 38
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 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). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document describes cryptographic algorithms for use with the This document describes several cryptographic algorithms for use with
Cryptographic Message Syntax (CMS) [CMS]. CMS is used to digitally the Cryptographic Message Syntax (CMS) [CMS]. CMS is used to
sign, digest, authenticate, or encrypt arbitrary messages. digitally sign, digest, authenticate, or encrypt arbitrary messages.
Once approved, this draft will obsolete section 12 of RFC 2630. The This document obsoletes section 12 of RFC 2630. [CMS] obsoletes the
companion document (draft-ietf-smime-rfc2630bis-02.txt) will obsolete rest of RFC 2630. Separation of the protocol and algorithm
the rest of RFC 2630. Separation of the protocol and algorithm specifications allows each one to be updated without impacting the
specifications allows the IETF to select different mandatory to other. However, the conventions for using additional algorithms with
implement algorithms in the future without reissuing the protocol the CMS are likely to be specified in separate documents.
document.
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 ................................................ 3 Table of Contents ................................................ 2
1 Introduction ................................................. 5 1 Introduction ................................................. 3
2 Message Digest Algorithms .................................... 35 2 Message Digest Algorithms .................................... 3
2.1 SHA-1 ................................................. 35 2.1 SHA-1 ................................................. 3
2.2 MD5 ................................................... 35 2.2 MD5 ................................................... 4
3 Signature Algorithms ......................................... 36 3 Signature Algorithms ......................................... 4
3.1 DSA ................................................... 36 3.1 DSA ................................................... 4
3.2 RSA ................................................... 36 3.2 RSA ................................................... 5
4 Key Management Algorithms .................................... 36 4 Key Management Algorithms .................................... 6
4.1 Key Agreement Algorithms .............................. 36 4.1 Key Agreement Algorithms .............................. 7
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ........ 37 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ........ 7
4.2 Key Transport Algorithms .............................. 38 4.1.2 X9.42 Static-Static Diffie-Hellman ........... 8
4.2.1 RSA .......................................... 39 4.2 Key Transport Algorithms .............................. 9
4.3 Symmetric Key-Encryption Key Algorithms ............... 39 4.2.1 RSA (PKCS #1 v1.5) ........................... 10
4.3.1 Triple-DES Key Wrap .......................... 40 4.3 Symmetric Key-Encryption Key Algorithms ............... 10
4.3.2 RC2 Key Wrap ................................. 41 4.3.1 Triple-DES Key Wrap .......................... 11
4.4 Key Derivation Algorithms ............................. 41 4.3.2 RC2 Key Wrap ................................. 11
4.4.1 PBKDF2 ....................................... 41 4.4 Key Derivation Algorithms ............................. 12
5 Content Encryption Algorithms ................................ 41 4.4.1 PBKDF2 ....................................... 13
5.1 Triple-DES CBC ........................................ 42 5 Content Encryption Algorithms ................................ 13
5.2 RC2 CBC ............................................... 42 5.1 Triple-DES CBC ........................................ 13
6 Message Authentication Code (MAC) Algorithms ................. 42 5.2 RC2 CBC ............................................... 14
6.1 HMAC with SHA-1 ....................................... 43 6 Message Authentication Code (MAC) Algorithms ................. 14
7 Triple-DES and RC2 Key Wrap Algorithms ....................... 43 6.1 HMAC with SHA-1 ....................................... 14
7.1 Key Checksum .......................................... 44 7 Triple-DES and RC2 Key Wrap Algorithms ....................... 15
7.2 Triple-DES Key Wrap ................................... 44 7.1 Key Checksum .......................................... 15
7.3 Triple-DES Key Unwrap ................................. 44 7.2 Triple-DES Key Wrap ................................... 16
7.4 RC2 Key Wrap .......................................... 45 7.3 Triple-DES Key Unwrap ................................. 16
7.5 RC2 Key Unwrap ........................................ 46 7.4 RC2 Key Wrap .......................................... 17
Appendix A: ASN.1 Module ........................................ 47 7.5 RC2 Key Unwrap ........................................ 17
References ....................................................... 55 Appendix A: ASN.1 Module ........................................ 18
Security Considerations .......................................... 56 References ....................................................... 21
Acknowledgments .................................................. 58 Security Considerations .......................................... 22
Author's Address ................................................. 59 Acknowledgments .................................................. 25
Full Copyright Statement ......................................... 60 Author's Address ................................................. 25
Full Copyright Statement ......................................... 26
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 algorithms that MUST be supported companion specification lists the common cryptographic algorithms.
by CMS implementations. It also lists algorithms that SHOULD be CMS implementations MAY support these algorithms; CMS implementations
supported by CMS implementations. Of course, CMS implementations MAY MAY support other algorithms as well.
support other algorithms as well.
Table 1 summarizes the algorithms that CMS implementations MUST
support and SHOULD support.
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 are identified by algorithm encoding [X.209-88]. Algorithm identifiers (which include ASN.1
identifiers (ASN.1 object identifiers), and some algorithms require object identifiers) identify cryptographic algorithms, and some
additional parameters. When needed, parameters are specified with an algorithms require additional parameters. When needed, parameters
ASN.1 structure. The algorithm identifier for each algorithm is are specified with an ASN.1 structure. The algorithm identifier for
specified, and, when needed, the parameter structure is specified. each algorithm is specified, and, when needed, the parameter
The fields in the CMS employed by each algorithm are identified. structure is specified. The fields in the CMS employed by each
algorithm are identified.
Table 1. CMS Implementation Algorithm Requirements
Algorithm Type MUST implement SHOULD implement
-----------------------------------------------------------------
Message Digest SHA-1 MD5
Signature DSA and RSA (1,2) --
Key Management
Key Agreement -- X9.42 E-S D-H
Key Transport RSA --
Symmetric KEK Wrap Triple-DES Key Wrap RC2 Key Wrap
Key Derivation PBKDF2 (3) --
Content Encryption Triple-DES CBC RC2 CBC
Message Authentication HMAC with SHA-1 (4) --
Note 1: CMS implementations MUST be able to verify signatures
with both DSA and RSA (PKCS #1 v1.5), and they MUST be
able to generate signatures with at least one of them.
Note 2: CMS implementations MUST support RSA (PKCS #1 v1.5) with
SHA-1. CMS implementations SHOULD support RSA
(PKCS #1 v1.5) with MD5.
Note 3: Only those CMS implementations that support password-
based key management MUST implement the PBKDF2 key
derivation algorithm as specified in RFC 2898 [PKCS#5].
Note 4: Only those CMS implementations that support
authenticated-data MUST implement the HMAC with SHA-1
algorithm as specified in RFC 2104 [HMAC].
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, MAY, and OPTIONAL are to be interpreted as SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described
described by Scott Bradner in [STDWORDS]. by Scott Bradner in [STDWORDS].
2 Message Digest Algorithms 2 Message Digest Algorithms
CMS implementations MUST support SHA-1. CMS implementations SHOULD This section specifies the conventions employed by CMS
support MD5. implementations that support SHA-1 or MD5.
Digest algorithm identifiers are located in the SignedData Digest algorithm identifiers are located in the SignedData
digestAlgorithms field, the SignerInfo digestAlgorithm field, the digestAlgorithms field, the SignerInfo digestAlgorithm field, the
DigestedData digestAlgorithm field, and the AuthenticatedData DigestedData digestAlgorithm field, and the AuthenticatedData
digestAlgorithm field. digestAlgorithm field.
Digest values are located in the DigestedData digest field the Digest values are located in the DigestedData digest field the
Message Digest authenticated attribute. In addition, digest values Message Digest authenticated attribute. In addition, digest values
are input to signature algorithms. are input to signature algorithms.
2.1 SHA-1 2.1 SHA-1
The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The The SHA-1 message digest algorithm is defined in FIPS Pub 180-1
algorithm identifier for SHA-1 is: [SHA1]. The algorithm identifier for SHA-1 is:
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 }
There are two possible encodings for the SHA-1 AlgorithmIdentifier
parameters field. The two alternatives arise from the fact that when
the 1988 syntax for AlgorithmIdentifier was translated into the 1997
syntax the OPTIONAL associated with the AlgorithmIdentifier
parameters got lost. Later the OPTIONAL was recovered via a defect
report, but by then many people thought that algorithm parameters
were mandatory. Because of this history some implementations encode
parameters as a NULL element and others omit them entirely. The
correct encoding is to omit the parameters field; however,
implementations MUST also handle a SHA-1 AlgorithmIdentifier
parameters field which contains a NULL.
The AlgorithmIdentifier parameters field is OPTIONAL. If present, The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field MUST contain an ASN.1 NULL. Implementations the parameters field MUST contain a NULL. Implementations SHOULD
SHOULD accept SHA-1 AlgorithmIdentifiers with absent parameters as accept SHA-1 AlgorithmIdentifiers with absent parameters as well as
well as NULL parameters. Implementations SHOULD generate SHA-1 NULL parameters. Implementations SHOULD generate SHA-1
AlgorithmIdentifiers with absent parameters. AlgorithmIdentifiers with absent parameters.
2.2 MD5 2.2 MD5
The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm
identifier for MD5 is: identifier for MD5 is:
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 }
The AlgorithmIdentifier parameters field MUST be present, and the The AlgorithmIdentifier parameters field MUST be present, and the
parameters field MUST contain NULL. Implementations MAY accept the parameters field MUST contain NULL. Implementations MAY accept the
MD5 AlgorithmIdentifiers with absent parameters as well as NULL MD5 AlgorithmIdentifiers with absent parameters as well as NULL
parameters. parameters.
3 Signature Algorithms 3 Signature Algorithms
CMS implementations MUST support both DSA and RSA (PKCS #1 v1.5). This section specifies the conventions employed by CMS
CMS implementations MUST be able to verify signatures with both DSA implementations that support DSA or RSA (PKCS #1 v1.5).
and RSA (PKCS #1 v1.5). CMS implementations MUST be able to generate
signatures with either DSA or RSA (PKCS #1 v1.5). CMS
implementations MAY be able to generate signatures with both DSA and
RSA (PKCS #1 v1.5).
Signature algorithm identifiers are located in the SignerInfo Signature algorithm identifiers are located in the SignerInfo
signatureAlgorithm field of SignedData. Also, signature algorithm signatureAlgorithm field of SignedData. Also, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field of identifiers are located in the SignerInfo signatureAlgorithm field of
countersignature attributes. countersignature attributes.
Signature values are located in the SignerInfo signature field of Signature values are located in the SignerInfo signature field of
SignedData. Also, signature values are located in the SignerInfo SignedData. Also, signature values are located in the SignerInfo
signature field of countersignature attributes. signature field of countersignature attributes.
3.1 DSA 3.1 DSA
The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA
always used with the SHA-1 message digest algorithm. MUST be used with the SHA-1 message digest algorithm.
The algorithm identifier for DSA subject public keys in certificates The algorithm identifier for DSA subject public keys in certificates
is: is:
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 1 } us(840) x9-57 (10040) x9cm(4) 1 }
DSA signature validation requires three parameters, commonly called DSA signature validation requires three parameters, commonly called
p, q, and g. When the id-dsa algorithm identifier is used, p, q, and g. When the id-dsa algorithm identifier is used,
AlgorithmIdentifier parameters field is optional. If present, the AlgorithmIdentifier parameters field is optional. If present, the
AlgorithmIdentifier parameters field MUST contain the three DSA AlgorithmIdentifier parameters field MUST contain the three DSA
parameter values encoded using the Dss-Parms type. If absent, the parameter values encoded using the Dss-Parms type. If absent, the
subject DSA public key uses the same DSA parameters as the subject DSA public key uses the same DSA parameters as the
certificate issuer. certificate issuer.
Dss-Parms ::= SEQUENCE { Dss-Parms ::= SEQUENCE {
p INTEGER, p INTEGER,
q INTEGER, q INTEGER,
g INTEGER } g INTEGER }
When the id-dsa algorithm identifier is used, the DSA public key, commonly called Y, MUST be encoded as an INTEGER. The output of this encoding is carried in the certificate subject public key. When the id-dsa algorithm identifier is used, the DSA public key,
commonly called Y, MUST be encoded as an INTEGER. The output of this
encoding is carried in the certificate subject public key.
Dss-Pub-Key ::= INTEGER -- Y Dss-Pub-Key ::= INTEGER -- Y
The algorithm identifier for DSA with SHA-1 signature values is: The algorithm identifier for DSA with SHA-1 signature values is:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 } us(840) x9-57 (10040) x9cm(4) 3 }
When the id-dsa-with-sha1 algorithm identifier is used, When the id-dsa-with-sha1 algorithm identifier is used,
AlgorithmIdentifier parameters field MUST be absent. AlgorithmIdentifier parameters field MUST be absent.
skipping to change at page 7, line 43 skipping to change at page 6, line 23
When the rsaEncryption algorithm identifier is used, the RSA public When the rsaEncryption algorithm identifier is used, the RSA public
key, which is composed of a modulus and a public exponent, MUST be key, which is composed of a modulus and a public exponent, MUST be
encoded using the RSAPublicKey type. The output of this encoding is encoded using the RSAPublicKey type. The output of this encoding is
carried in the certificate subject public key. carried in the certificate subject public key.
RSAPublicKey ::= SEQUENCE { RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n modulus INTEGER, -- n
publicExponent INTEGER } - e publicExponent INTEGER } - e
CMS implementations MUST support RSA (PKCS #1 v1.5) with SHA-1. CMS implementations SHOULD support RSA (PKCS #1 v1.5) with MD5. CMS implementations that support the RSA (PKCS #1 v1.5) signature
algorithm MUST also support the SHA-1 message digest algorithm. Such
implementations SHOULD also support MD5 message digest algorithm.
The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature values is: The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature
values is:
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature values is: The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature
values is:
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
When either the sha1WithRSAEncryption algorithm identifier or the md5WithRSAEncryption algorithm identifier is used, AlgorithmIdentifier parameters field MUST be NULL. When either the sha1WithRSAEncryption algorithm identifier or the
md5WithRSAEncryption algorithm identifier is used, the
AlgorithmIdentifier parameters field MUST be NULL.
When signing, the RSA algorithm generates a single value, and that value is used directly as the signature value. When signing, the RSA algorithm generates a single value, and that
value is used directly as the signature value.
4 Key Management Algorithms 4 Key Management Algorithms
CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric key-encryption keys, and passwords. CMS accommodates the following general key management techniques: key
agreement, key transport, previously distributed symmetric key-
encryption keys, and passwords.
4.1 Key Agreement Algorithms 4.1 Key Agreement Algorithms
CMS implementations SHOULD support key agreement using X9.42 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H). This section specifies the conventions employed by CMS
implementations that support key agreement using X9.42 Ephemeral-
Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie-
Hellman (X9.42 S-S D-H).
Any symmetric encryption algorithm that a CMS implementation includes as a content-encryption algorithm MUST also be included as a key-encryption algorithm. CMS implementations SHOULD include key agreement of Triple-DES pairwise key-encryption keys. CMS implementations SHOULD include key agreement of RC2 pairwise key-encryption keys. CMS implementations MUST include Triple-DES wrapping of Triple-DES content-encryption keys, and CMS implementations SHOULD include RC2 wrapping of RC2 content-encryption keys. The key wrap algorithms for Triple-DES and RC2 are described in section 7. Any symmetric encryption algorithm that a CMS implementation includes
as a content-encryption algorithm MUST also be included as a key-
encryption algorithm. The key wrap algorithms for Triple-DES and RC2
are described in section 7.
A CMS implementation MAY support mixed key-encryption and content-encryption algorithms. For example, a 128-bit RC2 content-encryption key MAY be wrapped with 168-bit Triple-DES key-encryption key. Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with 128-bit RC2 key-encryption key. A CMS implementation MAY support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption
key MAY be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with
128-bit RC2 key-encryption key.
For key agreement of RC2 key-encryption keys, 128 bits MUST be generated as input to the key expansion process used to compute the RC2 effective key [RC2]. For key agreement of RC2 key-encryption keys, 128 bits MUST be
generated as input to the key expansion process used to compute the
RC2 effective key [RC2].
Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields.
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Key wrap algorithm identifiers are located in the KeyWrapAlgorithm
parameters within the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field. Wrapped message-authentication keys are located
in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
RecipientEncryptedKeys encryptedKey field.
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are used as follows: Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631
[DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used as
follows:
version MUST be 3. version MUST be 3.
originator MUST be the originatorKey alternative. The originatorKey algorithm field MUST contain the dh-public-number object identifier with absent parameters. The originatorKey publicKey field MUST contain the sender's ephemeral public key. The dh-public-number object identifier is: originator MUST be the originatorKey alternative. The
originatorKey algorithm field MUST contain the dh-public-number
object identifier with absent parameters. The originatorKey
publicKey field MUST contain the sender's ephemeral public key.
The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
ukm MAY be absent. When present, the ukm is used to ensure that a ukm MAY be present or absent. When present, the ukm is used to
different key-encryption key is generated when the ephemeral ensure that a different key-encryption key is generated when the
private key might be used more than once. ephemeral private key 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 KeyWrapAlgorihtm, and this parameter MUST be present. The ESDH 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 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 discussed in section 7. The id-alg-ESDH algorithm algorithms are discussed in section 7. The id-alg-ESDH algorithm
identifier and parameter syntax is: identifier and parameter syntax is:
skipping to change at page 9, line 24 skipping to change at page 8, line 43
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 Ephemeral-Static Diffie- encryption key encrypted with the X9.42 Ephemeral-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.1.2 X9.42 Static-Static Diffie-Hellman
Static-Static Diffie-Hellman key agreement is defined in RFC 2631
[DH-X9.42]. When using Static-Static Diffie-Hellman, the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
used as follows:
version MUST be 3.
originator MUST be either the issuerAndSerialNumber or
subjectKeyIdentifier alternative. In both cases, the recipient's
certificate contains the sender's static public key, and the
certificate subject public key information field MUST contain the
dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
ukm MUST be present. The ukm ensures that a different key-
encryption key is generated for each message between the same
sender and recipient.
keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm
identifier. The algorithm identifier parameter field for id-alg-
SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Static-Static Diffie-
Hellman key agreement algorithm. Triple-DES and RC2 key wrap
algorithms are discussed in section 7. The id-alg-SSDH algorithm
identifier and parameter syntax is:
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey MUST contain the content-
encryption key encrypted with the X9.42 Static-Static Diffie-
Hellman generated pairwise key-encryption key using the algorithm
specified by the KeyWrapAlgortihm.
4.2 Key Transport Algorithms 4.2 Key Transport Algorithms
CMS implementations MUST support key transport using RSA (PKCS #1 This section specifies the conventions employed by CMS
v1.5). RSA implementations MUST support key transport of Triple-DES implementations that support key transport using RSA (PKCS #1 v1.5).
content-encryption keys. RSA implementations SHOULD support key
transport of RC2 content-encryption keys.
Key transport algorithm identifiers are located in the EnvelopedData Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
AuthenticatedData RecipientInfos KeyTransRecipientInfo
keyEncryptionAlgorithm fields.
Key transport encrypted content-encryption keys are located in the Key transport encrypted content-encryption keys are located in the
EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
field. Key transport encrypted message-authentication keys are field.
located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo
encryptedKey field.
4.2.1 RSA 4.2.1 RSA (PKCS #1 v1.5)
The RSA key transport algorithm is the RSA encryption scheme defined The RSA key transport algorithm is the RSA encryption scheme defined
in RFC 2313 [PKCS#1], block type is 02, where the message to be in RFC 2313 [PKCS#1], block type is 02, where the message to be
encrypted is the content-encryption key. The algorithm identifier encrypted is the content-encryption key. The algorithm identifier
for RSA is: for RSA (PKCS #1 v1.5) is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The AlgorithmIdentifier parameters field must be present, and the
parameters field must contain NULL. The AlgorithmIdentifier parameters field MUST be present, and the
parameters field MUST contain NULL.
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 (PKCS #1 v1.5) encryption. DES key prior to RSA encryption.
The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313
provide confidentiality has a known vulnerability. The vulnerability [PKCS#1], to provide confidentiality has a known vulnerability. The
is primarily relevant to usage in interactive applications rather vulnerability is primarily relevant to usage in interactive
than to store-and-forward environments. Further information and applications rather than to store-and-forward environments. Further
proposed countermeasures are discussed in the Security Considerations information and proposed countermeasures are discussed in the
section of this document and RFC <TBD> [MMA]. Security Considerations section of this document and RFC <TBD> [MMA].
Note that the same 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 scheme is called RSAES- [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called
PKCS1-v1_5. RSAES-PKCS1-v1_5.
4.3 Symmetric Key-Encryption Key Algorithms 4.3 Symmetric Key-Encryption Key Algorithms
CMS implementations MUST support symmetric key-encryption key This section specifies the conventions employed by CMS
management. CMS implementations MUST include Triple-DES key- implementations support symmetric key-encryption key management using
encryption keys wrapping Triple-DES content-encryption keys. CMS Triple-DES or RC2 key-encryption keys. When RC2 is supported, RC2
implementations SHOULD include RC2 key-encryption keys wrapping RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be
content-encryption keys. RC2 128-bit keys MUST be used as key- used with the RC2ParameterVersion parameter set to 58. A CMS
encryption keys, and they MUST be used with the RC2ParameterVersion implementation MAY support mixed key-encryption and content-
parameter set to 58. A CMS implementation MAY support mixed key- encryption algorithms. For example, a 40-bit RC2 content-encryption
encryption and content-encryption algorithms. For example, a 40-bit key MAY be wrapped with 168-bit Triple-DES key-encryption key or with
RC2 content-encryption key MAY be wrapped with 168-bit Triple-DES a 128-bit RC2 key-encryption key.
key-encryption key or with a 128-bit RC2 key-encryption key.
Key wrap algorithm identifiers are located in the EnvelopedData Key wrap algorithm identifiers are located in the EnvelopedData
RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KEKRecipientInfo AuthenticatedData RecipientInfos KEKRecipientInfo
keyEncryptionAlgorithm fields. keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message-
authentication keys are located in the AuthenticatedData authentication keys are located in the AuthenticatedData
RecipientInfos KEKRecipientInfo encryptedKey field. RecipientInfos KEKRecipientInfo encryptedKey field.
The output of a key agreement algorithm is a key-encryption key, and The output of a key agreement algorithm is a key-encryption key, and
this key-encryption key is used to encrypt the content-encryption this key-encryption key is used to encrypt the content-encryption
key. In conjunction with key agreement algorithms, CMS key. To support key agreement, key wrap algorithm identifiers are
implementations MUST include encryption of content-encryption keys located in the KeyWrapAlgorithm parameter of the EnvelopedData
with the pairwise key-encryption key generated using a key agreement
algorithm. To support key agreement, key wrap algorithm identifiers
are located in the KeyWrapAlgorithm parameter of the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields. Wrapped content-encryption keys are keyEncryptionAlgorithm fields. However, only key agreement
located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo algorithms that inherently provide authentication ought to be used
with AuthenticatedData. Wrapped content-encryption keys are located
in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
RecipientEncryptedKeys encryptedKey field, wrapped message- RecipientEncryptedKeys encryptedKey field, wrapped message-
authentication keys are located in the AuthenticatedData authentication keys are located in the AuthenticatedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field. encryptedKey field.
4.3.1 Triple-DES Key Wrap 4.3.1 Triple-DES Key Wrap
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)
skipping to change at page 12, line 38 skipping to change at page 12, line 26
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 7.4. The with a RC2 key-encryption key is specified in section 7.4. The
corresponding key unwrap algorithm is specified in section 7.5. corresponding key unwrap algorithm is specified in section 7.5.
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
implementations that support password-based key management using
PBKDF2.
Key derivation algorithms are used to convert a password into a key- Key derivation algorithms are used to convert a password into a key-
encryption key as part of the password-based key management encryption key as part of the password-based key management
technique. CMS implementations that support the password-based key technique. CMS implementations that support the password-based key
management technique MUST implement the PBKDF2 key derivation management technique MUST implement the PBKDF2 key derivation
algorithm specified in RFC 2898 [PKCS#5]. algorithm specified in RFC 2898 [PKCS#5].
Key derivation algorithm identifiers are located in the EnvelopedData Key derivation algorithm identifiers are located in the EnvelopedData
RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and
AuthenticatedData RecipientInfos PasswordRecipientInfo AuthenticatedData RecipientInfos PasswordRecipientInfo
keyDerivationAlgorithm fields. keyDerivationAlgorithm fields.
skipping to change at page 13, line 33 skipping to change at page 13, line 28
PBKDF2-params ::= SEQUENCE { PBKDF2-params ::= SEQUENCE {
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 DEFAULT hMAC-SHA1 } prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }
5 Content Encryption Algorithms 5 Content Encryption Algorithms
CMS implementations MUST support Three-Key Triple-DES in CBC mode. This section specifies the conventions employed by CMS
CMS implementations SHOULD support Two-Key Triple-DES in CBC mode. implementations that support content encryption using Three-Key
CMS implementations SHOULD support RC2 in CBC mode. Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC
mode.
Content encryption algorithms identifiers are located in the Content encryption algorithms identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the
EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.
Content encryption algorithms are used to encipher the content Content encryption algorithms are used to encipher the content
located in the EnvelopedData EncryptedContentInfo encryptedContent located in the EnvelopedData EncryptedContentInfo encryptedContent
field and the EncryptedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent
field. field.
skipping to change at page 14, line 43 skipping to change at page 14, line 39
The RC2 effective-key-bits (key size) greater than 32 and less than The RC2 effective-key-bits (key size) greater than 32 and less than
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), since Note that the value 160 must be encoded as two octets (00 A0), since
the one octet (A0) encoding represents a negative number. the one octet (A0) encoding represents a negative number.
6 Message Authentication Code Algorithms 6 Message Authentication Code Algorithms
CMS implementations that support authenticatedData MUST support HMAC This section specifies the conventions employed by CMS
with SHA-1. implementations that support the HMAC with SHA-1 message
authentication code (MAC).
MAC algorithm identifiers are located in the AuthenticatedData MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field. macAlgorithm field.
MAC values are located in the AuthenticatedData mac field. MAC values are located in the AuthenticatedData mac field.
6.1 HMAC with SHA-1 6.1 HMAC with SHA-1
The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The
algorithm identifier for HMAC with SHA-1 is: algorithm identifier for HMAC with SHA-1 is:
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 }
The AlgorithmIdentifier parameters field must be absent. The AlgorithmIdentifier parameters field must be absent.
7 Triple-DES and RC2 Key Wrap Algorithms 7 Triple-DES and RC2 Key Wrap Algorithms
CMS implementations MUST include encryption of a Triple-DES content- This section specifies algorithms for wrapping content-encryption
encryption key with a Triple-DES key-encryption key using the keys with Triple-DES and RC2 key-encryption keys. Encryption of a
algorithm specified in Sections 7.2 and 7.3. CMS implementations Triple-DES content-encryption key with a Triple-DES key-encryption
SHOULD include encryption of a RC2 content-encryption key with a RC2 key uses the algorithm specified in sections 7.2 and 7.3. Encryption
key-encryption key using the algorithm specified in Sections 7.4 and of a RC2 content-encryption key with a RC2 key-encryption key uses
7.5. Triple-DES and RC2 content-encryption keys are encrypted in the algorithm specified in sections 7.4 and 7.5. Both of these
algorithms rely on the key checksum algorithm specified in section
7.1. Triple-DES and RC2 content-encryption keys are encrypted in
Cipher Block Chaining (CBC) mode [MODES]. Cipher Block Chaining (CBC) mode [MODES].
Key Transport algorithms allow for the content-encryption key to be Key Transport algorithms allow for the content-encryption key to be
directly encrypted; however, key agreement and symmetric key- directly encrypted; however, key agreement and symmetric key-
encryption key algorithms encrypt the content-encryption key with a encryption key algorithms encrypt the content-encryption key with a
second symmetric encryption algorithm. This section describes how second symmetric encryption algorithm. This section describes how
the Triple-DES or RC2 content-encryption key is formatted and the Triple-DES or RC2 content-encryption key is formatted and
encrypted. encrypted.
Key agreement algorithms generate a pairwise key-encryption key, and Key agreement algorithms generate a pairwise key-encryption key, and
skipping to change at page 16, line 7 skipping to change at page 15, line 50
The same algorithm identifier is used for both Two-key Triple-DES and The same algorithm identifier is used for both Two-key Triple-DES and
Three-key Triple-DES. When the length of the content-encryption key Three-key Triple-DES. When the length of the content-encryption key
to be wrapped is a Two-key Triple-DES key, a third key with the same to be wrapped is a Two-key Triple-DES key, a third key with the same
value as the first key is created. Thus, all Triple-DES content- value as the first key is created. Thus, all Triple-DES content-
encryption keys are wrapped like Three-key Triple-DES keys. However, encryption keys are wrapped like Three-key Triple-DES keys. However,
a Two-key Triple-DES key MUST NOT be used to wrap a Three-key Triple- a Two-key Triple-DES key MUST NOT be used to wrap a Three-key Triple-
DES key. DES key.
7.1 Key Checksum 7.1 Key Checksum
The CMS Checksum Algorithm is used to provide a content-encryption The CMS Key Checksum Algorithm is used to provide a content-
key integrity check value. The algorithm is: encryption key integrity check value. The algorithm is:
1. Compute a 20 octet SHA-1 [SHA1] message digest on the 1. Compute a 20 octet SHA-1 [SHA1] message digest on the
content-encryption key. content-encryption key.
2. Use the most significant (first) eight octets of the message 2. Use the most significant (first) eight octets of the message
digest value as the checksum value. digest value as the checksum value.
7.2 Triple-DES Key Wrap 7.2 Triple-DES Key Wrap
The Triple-DES key wrap algorithm encrypts a Triple-DES content- The Triple-DES key wrap algorithm encrypts a Triple-DES content-
encryption key with a Triple-DES key-encryption key. The Triple-DES encryption key with a Triple-DES key-encryption key. The Triple-DES
skipping to change at page 19, line 50 skipping to change at page 19, line 33
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
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 }
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 } rsadsi(113549) encryptionAlgorithm(3) 2 }
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
skipping to change at page 22, line 26 skipping to change at page 22, line 14
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.
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
X.509 Public Key Infrastructure: Certificate and CRL
Profile. RFC <TBD>. <Date>.
{draft-ietf-pkix-new-part1-*.txt}
RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness
Recommendations for Security. RFC 1750. December 1994. Recommendations for Security. RFC 1750. December 1994.
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
skipping to change at page 22, line 48 skipping to change at page 22, line 41
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 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 cryptographic algorithms for use with CMS. the conventions for using several cryptographic algorithms for use
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 messages 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 data origin authentication, authentication keys must itself provide authentication, otherwise the
otherwise the message content is delivered with integrity from an message content is delivered with integrity from an unknown source.
unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman
Diffie-Hellman [DH-X9.42] provide the necessary data origin [DH-X9.42] provide the necessary data origin authentication. Static-
authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide Static Diffie-Hellman [DH-X9.42] does provide the necessary data
the necessary data origin authentication when both the originator and origin authentication when both the originator and recipient public
recipient public keys are bound to appropriate identities in X.509 keys are bound to appropriate identities in X.509 certificates
certificates. [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. message 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), and message-authentication keys, initialization vectors (IVs), one-time
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 keys can result in generators (PRNGs) to generate cryptographic such values can result
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
skipping to change at page 24, line 22 skipping to change at page 24, line 17
to encrypt a RC2 [RC2] content-encryption key with a RC2 key- to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
encryption key. The key wrap algorithms make use of CBC mode encryption key. The key wrap algorithms make 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.
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared for to be readily inserted. That is, implementers should be prepared to
the set of mandatory to implement algorithms to change over time. regularly update the set of algorithms in their implementations.
Users of CMS, particularly those employing CMS to support interactive Users of the CMS, particularly those employing the CMS to support
applications, should be aware that PKCS #1 Version 1.5 as specified interactive applications, should be aware that RSA (PKCS #1 v1.5), as
in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen
attacks when applied for encryption purposes. Exploitation of this ciphertext attacks when applied for encryption purposes.
identified vulnerability, revealing the result of a particular RSA Exploitation of this identified vulnerability, revealing the result
decryption, requires access to an oracle which will respond to a of a particular RSA decryption, requires access to an oracle which
large number of ciphertexts (based on currently available results, will respond to a large number of ciphertexts (based on currently
hundreds of thousands or more), which are constructed adaptively in available results, hundreds of thousands or more), which are
response to previously-received replies providing information on the constructed adaptively in response to previously-received replies
successes or failures of attempted decryption operations. As a providing information on the successes or failures of attempted
result, the attack appears significantly less feasible to perpetrate decryption operations. As a result, the attack appears significantly
for store-and-forward S/MIME environments than for directly less feasible to perpetrate for store-and-forward S/MIME environments
interactive protocols. Where CMS constructs are applied as an than for directly interactive protocols. Where the CMS constructs
intermediate encryption layer within an interactive request-response are applied as an intermediate encryption layer within an interactive
communications environment, exploitation could be more feasible. request-response communications environment, exploitation could be
more feasible.
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
[NEWPKCS#1]. This new document supersedes RFC 2313. PKCS #1 Version [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1
2.0 preserves support for the encryption padding format defined in Version 2.0 preserves support for the encryption padding format
PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative. defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 alternative. To resolve the adaptive chosen ciphertext
Version 2.0 specifies and recommends use of Optimal Asymmetric vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
Encryption Padding (OAEP) when RSA encryption is used to provide of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
confidentiality. Designers of protocols and systems employing CMS is used to provide confidentiality. Designers of protocols and
for interactive environments should either consider usage of OAEP, or systems employing CMS for interactive environments should either
should ensure that information which could reveal the success or consider usage of OAEP, or should ensure that information which could
failure of attempted PKCS #1 Version 1.5 decryption operations is not reveal the success or failure of attempted PKCS #1 Version 1.5
provided. Support for OAEP will likely be added to a future version decryption operations is not provided. Support for OAEP will likely
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 <TBD> [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 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,
 End of changes. 

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