draft-ietf-smime-cmsalg-03.txt | draft-ietf-smime-cmsalg-04.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 August 2001 | expires in six months September 2001 | |||

Cryptographic Message Syntax (CMS) Algorithms | Cryptographic Message Syntax (CMS) Algorithms | |||

<draft-ietf-smime-cmsalg-03.txt> | <draft-ietf-smime-cmsalg-04.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 2, line 25 | skipping to change at page 2, line 25 | |||

3.1 DSA ................................................... 4 | 3.1 DSA ................................................... 4 | |||

3.2 RSA ................................................... 5 | 3.2 RSA ................................................... 5 | |||

4 Key Management Algorithms .................................... 6 | 4 Key Management Algorithms .................................... 6 | |||

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 ........ 7 | |||

4.1.2 X9.42 Static-Static Diffie-Hellman ........... 8 | 4.1.2 X9.42 Static-Static Diffie-Hellman ........... 8 | |||

4.2 Key Transport Algorithms .............................. 9 | 4.2 Key Transport Algorithms .............................. 9 | |||

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 ............... 10 | 4.3 Symmetric Key-Encryption Key Algorithms ............... 10 | |||

4.3.1 Triple-DES Key Wrap .......................... 11 | 4.3.1 Triple-DES Key Wrap .......................... 11 | |||

4.3.2 RC2 Key Wrap ................................. 11 | 4.3.2 RC2 Key Wrap ................................. 12 | |||

4.4 Key Derivation Algorithms ............................. 12 | 4.4 Key Derivation Algorithms ............................. 12 | |||

4.4.1 PBKDF2 ....................................... 13 | 4.4.1 PBKDF2 ....................................... 13 | |||

5 Content Encryption Algorithms ................................ 13 | 5 Content Encryption Algorithms ................................ 13 | |||

5.1 Triple-DES CBC ........................................ 13 | 5.1 Triple-DES CBC ........................................ 14 | |||

5.2 RC2 CBC ............................................... 14 | 5.2 RC2 CBC ............................................... 14 | |||

6 Message Authentication Code (MAC) Algorithms ................. 14 | 6 Message Authentication Code (MAC) Algorithms ................. 15 | |||

6.1 HMAC with SHA-1 ....................................... 14 | 6.1 HMAC with SHA-1 ....................................... 15 | |||

7 Triple-DES and RC2 Key Wrap Algorithms ....................... 15 | Appendix A: ASN.1 Module ........................................ 16 | |||

7.1 Key Checksum .......................................... 15 | References ....................................................... 19 | |||

7.2 Triple-DES Key Wrap ................................... 16 | Security Considerations .......................................... 20 | |||

7.3 Triple-DES Key Unwrap ................................. 16 | Acknowledgments .................................................. 23 | |||

7.4 RC2 Key Wrap .......................................... 17 | Author's Address ................................................. 23 | |||

7.5 RC2 Key Unwrap ........................................ 17 | Full Copyright Statement ......................................... 23 | |||

Appendix A: ASN.1 Module ........................................ 18 | ||||

References ....................................................... 21 | ||||

Security Considerations .......................................... 22 | ||||

Acknowledgments .................................................. 25 | ||||

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 common cryptographic algorithms. | companion specification lists the common cryptographic algorithms. | |||

CMS implementations MAY support these algorithms; CMS implementations | Implementations of the CMS MAY support these algorithms; | |||

MAY support other algorithms as well. | implementations of the CMS MAY support other algorithms as well. | |||

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 3, line 36 | skipping to change at page 3, line 36 | |||

2 Message Digest Algorithms | 2 Message Digest Algorithms | |||

This section specifies the conventions employed by CMS | This section specifies the conventions employed by CMS | |||

implementations that support SHA-1 or MD5. | implementations that support SHA-1 or MD5. | |||

Digest algorithm identifiers are located in the SignedData | Digest algorithm identifiers are located in the SignedData | |||

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 and 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 message digest algorithm is defined in FIPS Pub 180-1 | The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 | |||

[SHA1]. The 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 } | |||

skipping to change at page 4, line 14 | skipping to change at page 4, line 14 | |||

report, but by then many people thought that algorithm parameters | report, but by then many people thought that algorithm parameters | |||

were mandatory. Because of this history some implementations encode | were mandatory. Because of this history some implementations encode | |||

parameters as a NULL element and others omit them entirely. The | parameters as a NULL element and others omit them entirely. The | |||

correct encoding is to omit the parameters field; however, | correct encoding is to omit the parameters field; however, | |||

implementations MUST also handle a SHA-1 AlgorithmIdentifier | implementations MUST also handle a SHA-1 AlgorithmIdentifier | |||

parameters field which contains a NULL. | 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 a NULL. Implementations MUST | the parameters field MUST contain a NULL. Implementations MUST | |||

accept SHA-1 AlgorithmIdentifiers with absent parameters. | accept SHA-1 AlgorithmIdentifiers with absent parameters. | |||

Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent | Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent | |||

parameters. Implementations SHOULD generate SHA-1 | 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 } | |||

skipping to change at page 7, line 16 | skipping to change at page 7, line 16 | |||

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 section 7. | described in RFC <TBD> [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 9 | skipping to change at page 8, line 9 | |||

originator MUST be the originatorKey alternative. The | originator MUST be the originatorKey alternative. The | |||

originatorKey algorithm field MUST contain the dh-public-number | originatorKey algorithm field MUST contain the dh-public-number | |||

object identifier with absent parameters. The originatorKey | object identifier with absent parameters. The originatorKey | |||

publicKey field MUST contain the sender's ephemeral public key. | publicKey field MUST contain the sender's ephemeral public key. | |||

The dh-public-number object identifier is: | 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 present or absent. CMS implementations MUST support | ukm may be present or absent. CMS implementations MUST support | |||

ukm being absent, and CMS implementations SHOULD support be | ukm being absent, and CMS implementations SHOULD support ukm being | |||

present. When present, the ukm is used to ensure that a different | present. When present, the ukm is used to ensure that a different | |||

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 discussed in section 7. The id-alg-ESDH algorithm | algorithms are described in RFC <TBD> [WRAP]. The id-alg-ESDH | |||

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 | |||

KeyAgreeRecipientIdentifier MUST contain either the | KeyAgreeRecipientIdentifier MUST contain either the | |||

skipping to change at page 9, line 4 | skipping to change at page 9, line 4 | |||

Static-Static Diffie-Hellman key agreement is defined in RFC 2631 | Static-Static Diffie-Hellman key agreement is defined in RFC 2631 | |||

[DH-X9.42]. When using Static-Static Diffie-Hellman, the | [DH-X9.42]. When using Static-Static Diffie-Hellman, the | |||

EnvelopedData RecipientInfos KeyAgreeRecipientInfo and | EnvelopedData RecipientInfos KeyAgreeRecipientInfo and | |||

AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are | AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are | |||

used as follows: | used as follows: | |||

version MUST be 3. | version MUST be 3. | |||

originator MUST be either the issuerAndSerialNumber or | originator MUST be either the issuerAndSerialNumber or | |||

subjectKeyIdentifier alternative. In both cases, the recipient's | subjectKeyIdentifier alternative. In both cases, the originator's | |||

certificate contains the sender's static public key, and the | certificate contains the sender's static public key. RFC <TBD> | |||

certificate subject public key information field MUST contain the | [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and | |||

dh-public-number object identifier is: | values that are included in the originator's certificate. The | |||

originator's certificate subject public key information field MUST | ||||

contain the dh-public-number object identifier: | ||||

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 MUST be present. The ukm ensures that a different key- | ukm MUST be present. The ukm ensures that a different key- | |||

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 discussed in section 7. The id-alg-SSDH algorithm | algorithms are described in RFC <TBD> [WRAP]. The id-alg-SSDH | |||

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 | |||

skipping to change at page 10, line 40 | skipping to change at page 10, line 41 | |||

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 <TBD> [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 support symmetric key-encryption key management using | implementations that support symmetric key-encryption key management | |||

Triple-DES or RC2 key-encryption keys. When RC2 is supported, RC2 | using Triple-DES or RC2 key-encryption keys. When RC2 is supported, | |||

128-bit keys MUST be used as key-encryption keys, and they MUST be | RC2 128-bit keys MUST be used as key-encryption keys, and they MUST | |||

used with the RC2ParameterVersion parameter set to 58. A CMS | be used with the RC2ParameterVersion parameter set to 58. A CMS | |||

implementation MAY support mixed key-encryption and content- | implementation MAY support mixed key-encryption and content- | |||

encryption algorithms. For example, a 40-bit RC2 content-encryption | encryption algorithms. For example, a 40-bit RC2 content-encryption | |||

key MAY be wrapped with 168-bit Triple-DES key-encryption key or with | key MAY be wrapped with 168-bit Triple-DES key-encryption key or with | |||

a 128-bit RC2 key-encryption key. | 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. | |||

skipping to change at page 11, line 40 | skipping to change at page 11, line 42 | |||

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 7.2. The corresponding key unwrap algorithm is specified in | section 3.1 of RFC <TBD> [WRAP]. The corresponding key unwrap | |||

section 7.3. | algorithm is specified in section 3.2 of RFC <TBD> [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 28 | skipping to change at page 12, line 35 | |||

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 7.4. The | with a RC2 key-encryption key is specified in section 4.1 of RFC | |||

corresponding key unwrap algorithm is specified in section 7.5. | <TBD> [WRAP]. The corresponding key unwrap algorithm is specified | |||

4.2 of RFC <TBD> [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 12, line 51 | skipping to change at page 13, line 11 | |||

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. | technique. | |||

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. | |||

The key-encryption key that is derived from the password is used to | The key-encryption key that is derived from the password is used to | |||

encrypt the content-encryption key | encrypt the content-encryption key. | |||

The content-encryption keys encrypted with password-derived key- | The content-encryption keys encrypted with password-derived key- | |||

encryption keys are located in the EnvelopedData RecipientInfos | encryption keys are located in the EnvelopedData RecipientInfos | |||

PasswordRecipientInfo encryptedKey field. The message-authentication | PasswordRecipientInfo encryptedKey field. The message-authentication | |||

keys encrypted with password-derived key-encryption keys are located | keys encrypted with password-derived key-encryption keys are located | |||

in the AuthenticatedData RecipientInfos PasswordRecipientInfo | in the AuthenticatedData RecipientInfos PasswordRecipientInfo | |||

encryptedKey field. | encryptedKey field. | |||

4.4.1 PBKDF2 | 4.4.1 PBKDF2 | |||

The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5]. | The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5]. | |||

skipping to change at page 15, line 30 | skipping to change at page 16, line 5 | |||

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 encode parameters as a NULL element and others omit | |||

them entirely. CMS implementations that support HMAC with SHA-1 MUST | them entirely. CMS implementations that support HMAC with SHA-1 MUST | |||

handle both an AlgorithmIdentifier parameters field which contains a | handle both an AlgorithmIdentifier parameters field which contains a | |||

NULL and an AlgorithmIdentifier with an absent parameters. | NULL and an AlgorithmIdentifier with an absent parameters. | |||

7 Triple-DES and RC2 Key Wrap Algorithms | ||||

This section specifies algorithms for wrapping content-encryption | ||||

keys with Triple-DES and RC2 key-encryption keys. Encryption of a | ||||

Triple-DES content-encryption key with a Triple-DES key-encryption | ||||

key uses the algorithm specified in sections 7.2 and 7.3. Encryption | ||||

of a RC2 content-encryption key with a RC2 key-encryption key uses | ||||

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]. | ||||

Key Transport algorithms allow for the content-encryption key to be | ||||

directly encrypted; however, key agreement and symmetric key- | ||||

encryption key algorithms encrypt the content-encryption key with a | ||||

second symmetric encryption algorithm. This section describes how | ||||

the Triple-DES or RC2 content-encryption key is formatted and | ||||

encrypted. | ||||

Key agreement algorithms generate a pairwise key-encryption key, and | ||||

a key wrap algorithm is used to encrypt the content-encryption key | ||||

with the pairwise key-encryption key. Similarly, a key wrap | ||||

algorithm is used to encrypt the content-encryption key in a | ||||

previously distributed key-encryption key. | ||||

The key-encryption key is generated by the key agreement algorithm or | ||||

distributed out of band. 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]. | ||||

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 | ||||

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- | ||||

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- | ||||

DES key. | ||||

7.1 Key Checksum | ||||

The CMS Key Checksum Algorithm is used to provide a content- | ||||

encryption key integrity check value. The algorithm is: | ||||

1. Compute a 20 octet SHA-1 [SHA1] message digest on the | ||||

content-encryption key. | ||||

2. Use the most significant (first) eight octets of the message | ||||

digest value as the checksum value. | ||||

7.2 Triple-DES Key Wrap | ||||

The Triple-DES key wrap algorithm encrypts a Triple-DES content- | ||||

encryption key with a Triple-DES key-encryption key. The Triple-DES | ||||

key wrap algorithm is: | ||||

1. Set odd parity for each of the DES key octets comprising | ||||

the content-encryption key, call the result CEK. | ||||

2. Compute an 8 octet key checksum value on CEK as described above | ||||

in Section 7.1, call the result ICV. | ||||

3. Let CEKICV = CEK || ICV. | ||||

4. Generate 8 octets at random, call the result IV. | ||||

5. Encrypt CEKICV in CBC mode using the key-encryption key. Use | ||||

the random value generated in the previous step as the | ||||

initialization vector (IV). Call the ciphertext TEMP1. | ||||

6. Let TEMP2 = IV || TEMP1. | ||||

7. Reverse the order of the octets in TEMP2. That is, the most | ||||

significant (first) octet is swapped with the least significant | ||||

(last) octet, and so on. Call the result TEMP3. | ||||

8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use | ||||

an initialization vector (IV) of 0x4adda22c79e82105. | ||||

The ciphertext is 40 octets long. | ||||

Note: When the same content-encryption key is wrapped in different | ||||

key-encryption keys, a fresh initialization vector (IV) must be | ||||

generated for each invocation of the key wrap algorithm. | ||||

7.3 Triple-DES Key Unwrap | ||||

The Triple-DES key unwrap algorithm decrypts a Triple-DES content- | ||||

encryption key using a Triple-DES key-encryption key. The Triple-DES | ||||

key unwrap algorithm is: | ||||

1. If the wrapped content-encryption key is not 40 octets, then | ||||

error. | ||||

2. Decrypt the wrapped content-encryption key in CBC mode using | ||||

the key-encryption key. Use an initialization vector (IV) | ||||

of 0x4adda22c79e82105. Call the output TEMP3. | ||||

3. Reverse the order of the octets in TEMP3. That is, the most | ||||

significant (first) octet is swapped with the least significant | ||||

(last) octet, and so on. Call the result TEMP2. | ||||

4. Decompose the TEMP2 into IV and TEMP1. IV is the most | ||||

significant (first) 8 octets, and TEMP1 is the least significant | ||||

(last) 32 octets. | ||||

5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use | ||||

the IV value from the previous step as the initialization vector. | ||||

Call the ciphertext CEKICV. | ||||

6. Decompose the CEKICV into CEK and ICV. CEK is the most significant | ||||

(first) 24 octets, and ICV is the least significant (last) 8 octets. | ||||

7. Compute an 8 octet key checksum value on CEK as described above | ||||

in Section 7.1. If the computed key checksum value does not | ||||

match the decrypted key checksum value, ICV, then error. | ||||

8. Check for odd parity each of the DES key octets comprising CEK. | ||||

If parity is incorrect, then there is an error. | ||||

9. Use CEK as the content-encryption key. | ||||

7.4 RC2 Key Wrap | ||||

The RC2 key wrap algorithm encrypts a RC2 content-encryption key with | ||||

a RC2 key-encryption key. The RC2 key wrap algorithm is: | ||||

1. Let the content-encryption key be called CEK, and let the length | ||||

of the content-encryption key in octets be called LENGTH. LENGTH | ||||

is a single octet. | ||||

2. Let LCEK = LENGTH || CEK. | ||||

3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple | ||||

of 8, the PAD has a length of zero. If the length of LCEK is | ||||

not a multiple of 8, then PAD contains the fewest number of | ||||

random octets to make the length of LCEKPAD a multiple of 8. | ||||

4. Compute an 8 octet key checksum value on LCEKPAD as described | ||||

above in Section 7.1, call the result ICV. | ||||

5. Let LCEKPADICV = LCEKPAD || ICV. | ||||

6. Generate 8 octets at random, call the result IV. | ||||

7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. | ||||

Use the random value generated in the previous step as the | ||||

initialization vector (IV). Call the ciphertext TEMP1. | ||||

8. Let TEMP2 = IV || TEMP1. | ||||

9. Reverse the order of the octets in TEMP2. That is, the most | ||||

significant (first) octet is swapped with the least significant | ||||

(last) octet, and so on. Call the result TEMP3. | ||||

10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use | ||||

an initialization vector (IV) of 0x4adda22c79e82105. | ||||

Note: When the same content-encryption key is wrapped in different | ||||

key-encryption keys, a fresh initialization vector (IV) must be | ||||

generated for each invocation of the key wrap algorithm. | ||||

7.5 RC2 Key Unwrap | ||||

The RC2 key unwrap algorithm decrypts a RC2 content-encryption key | ||||

using a RC2 key-encryption key. The RC2 key unwrap algorithm is: | ||||

1. If the wrapped content-encryption key is not a multiple of 8 | ||||

octets, then error. | ||||

2. Decrypt the wrapped content-encryption key in CBC mode using | ||||

the key-encryption key. Use an initialization vector (IV) | ||||

of 0x4adda22c79e82105. Call the output TEMP3. | ||||

3. Reverse the order of the octets in TEMP3. That is, the most | ||||

significant (first) octet is swapped with the least significant | ||||

(last) octet, and so on. Call the result TEMP2. | ||||

4. Decompose the TEMP2 into IV and TEMP1. IV is the most | ||||

significant (first) 8 octets, and TEMP1 is the remaining octets. | ||||

5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use | ||||

the IV value from the previous step as the initialization vector. | ||||

Call the plaintext LCEKPADICV. | ||||

6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the | ||||

least significant (last) octet 8 octets. LCEKPAD is the | ||||

remaining octets. | ||||

7. Compute an 8 octet key checksum value on LCEKPAD as described | ||||

above in Section 7.1. If the computed key checksum value does | ||||

not match the decrypted key checksum value, ICV, then error. | ||||

8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the | ||||

most significant (first) octet. CEK is the following LENGTH | ||||

octets. PAD is the remaining octets, if any. | ||||

9. If the length of PAD is more than 7 octets, then error. | ||||

10. Use CEK as the content-encryption key. | ||||

Appendix A: ASN.1 Module | Appendix A: 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 | |||

skipping to change at page 22, line 10 | skipping to change at page 19, line 10 | |||

prf AlgorithmIdentifier | prf AlgorithmIdentifier | |||

DEFAULT { algorithm hMAC-SHA1, parameters NULL } } | DEFAULT { algorithm hMAC-SHA1, parameters NULL } } | |||

END -- of CryptographicMessageSyntaxAlgorithms | END -- of CryptographicMessageSyntaxAlgorithms | |||

References | 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. | |||

CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>. <Date>. | CERTALGS Bassham, L., R. Housley, and W. Polk. Algorithms and | |||

{draft-ietf-smime-rfc2630bis-*.txt} | Identifiers for the Internet X.509 Public Key | |||

Infrastructure Certificate and CRL Profile. RFC <TBD>. | ||||

<Date>. {draft-ietf-pkix-ipki-pkalgs-03.txt} | ||||

CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>. | ||||

<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. | |||

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. | |||

skipping to change at page 23, line 14 | skipping to change at page 20, line 16 | |||

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>. | ||||

<Date>. {draft-ietf-smime-key-wrap-*.txt} | ||||

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 | |||

skipping to change at page 24, line 37 | skipping to change at page 21, line 42 | |||

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. | |||

Section 7 specifies key wrap algorithms used to encrypt a Triple-DES | RFC <TBD> [WRAP] specifies key wrap algorithms used to encrypt a | |||

[3DES] content-encryption key with a Triple-DES key-encryption key or | Triple-DES content-encryption key with a Triple-DES key-encryption | |||

to encrypt a RC2 [RC2] content-encryption key with a RC2 key- | key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key- | |||

encryption key. The key wrap algorithms make 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. | |||

Implementers should be aware that cryptographic algorithms become | Implementers should be aware that cryptographic algorithms become | |||

weaker with time. As new cryptanalysis 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 | |||

End of changes. | ||||

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