draft-ietf-smime-key-wrap-01.txt | rfc3217.txt | |||
---|---|---|---|---|

S/MIME Working Group R. Housley | Network Working Group R. Housley | |||

Internet Draft RSA Laboratories | Request for Comments: 3217 RSA Laboratories | |||

expires in six months September 2001 | Category: Informational December 2001 | |||

Triple-DES and RC2 Key Wrapping | Triple-DES and RC2 Key Wrapping | |||

<draft-ietf-smime-key-wrap-01.txt> | ||||

Status of this Memo | Status of this Memo | |||

This document is an Internet-Draft and is in full conformance with | This memo provides information for the Internet community. It does | |||

all provisions of Section 10 of RFC2026. Internet-Drafts are working | not specify an Internet standard of any kind. Distribution of this | |||

documents of the Internet Engineering Task Force (IETF), its areas, | memo is unlimited. | |||

and its working groups. Note that other groups may also distribute | ||||

working documents as Internet-Drafts. | ||||

Internet-Drafts are draft documents valid for a maximum of six months | ||||

and may be updated, replaced, or obsoleted by other documents at any | ||||

time. It is inappropriate to use Internet-Drafts as reference | ||||

material or to cite them other than as "work in progress." | ||||

The list of current Internet-Drafts can be accessed at | ||||

http://www.ietf.org/1id-abstracts.html | ||||

The list of Internet-Draft Shadow Directories can be accessed at | Copyright Notice | |||

http://www.ietf.org/shadow.html. | ||||

To view the entire list of current Internet-Drafts, please check the | Copyright (C) The Internet Society (2001). All Rights Reserved. | |||

"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow | ||||

Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern | ||||

Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific | ||||

Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). | ||||

Abstract | Abstract | |||

This document specifies the algorithm for wrapping one Triple-DES | This document specifies the algorithm for wrapping one Triple-DES key | |||

[3DES] key with another Triple-DES key and the algorithm for wrapping | with another Triple-DES key and the algorithm for wrapping one RC2 | |||

one RC2 [RC2] key with another RC2 key. These key wrap algorithms | key with another RC2 key. These key wrap algorithms were originally | |||

were originally published in section 12.6 of RFC 2630 [CMS]. They | published in section 12.6 of RFC 2630. They are republished since | |||

are republished since these key wrap algorithms have been found to be | these key wrap algorithms have been found to be useful in contexts | |||

useful in contexts beyond those supported by RFC 2630. | beyond those supported by RFC 2630. | |||

This draft is being discussed on the "ietf-smime" mailing list. To | ||||

join the list, send a message to <ietf-smime-request@imc.org> with | ||||

the single word "subscribe" in the body of the message. Also, there | ||||

is a Web site for the mailing list at <http://www.imc.org/ietf- | ||||

smime/>. | ||||

1 Introduction | 1 Introduction | |||

Management of symmetric cryptographic keys often leads to situations | Management of symmetric cryptographic keys often leads to situations | |||

where one symmetric key is used to encrypt (or wrap) another. Key | where one symmetric key is used to encrypt (or wrap) another. Key | |||

wrap algorithms are commonly used in two situations. First, key | wrap algorithms are commonly used in two situations. First, key | |||

agreement algorithms (such as Diffie-Hellman [DH-X9.42]) generate a | agreement algorithms (such as Diffie-Hellman [DH-X9.42]) generate a | |||

pairwise key-encryption key, and a key wrap algorithm is used to | pairwise key-encryption key, and a key wrap algorithm is used to | |||

encrypt the content-encryption key or a multicast key with the | encrypt the content-encryption key or a multicast key with the | |||

pairwise key-encryption key. Second, a key wrap algorithm is used to | pairwise key-encryption key. Second, a key wrap algorithm is used to | |||

skipping to change at page 2, line 37 | skipping to change at page 2, line 14 | |||

In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, | In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, | |||

SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described | SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described | |||

by Scott Bradner in [STDWORDS]. | by Scott Bradner in [STDWORDS]. | |||

2 Key Checksum | 2 Key Checksum | |||

The key checksum algorithm is used to provide a key integrity check | The key checksum algorithm is used to provide a key integrity check | |||

value. The algorithm is: | value. The algorithm is: | |||

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

that is to be wrapped. | to be wrapped. | |||

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

3 Triple-DES Key Wrapping and Unwrapping | 3 Triple-DES Key Wrapping and Unwrapping | |||

This section specifies the algorithms for wrapping and unwrapping one | This section specifies the algorithms for wrapping and unwrapping one | |||

Triple-DES key with another Triple-DES key [3DES]. | Triple-DES key with another Triple-DES key [3DES]. | |||

The same key wrap algorithm is used for both Two-key Triple-DES and | The same key wrap algorithm is used for both Two-key Triple-DES and | |||

Three-key Triple-DES keys. When a Two-key Triple-DES key is to be | Three-key Triple-DES keys. When a Two-key Triple-DES key is to be | |||

skipping to change at page 3, line 13 | skipping to change at page 2, line 39 | |||

key Triple-DES key that is comprised of three unique DES keys. | key Triple-DES key that is comprised of three unique DES keys. | |||

3.1 Triple-DES Key Wrap | 3.1 Triple-DES Key Wrap | |||

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

Triple-DES key-encryption key. The Triple-DES key wrap algorithm is: | 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 | 1. Set odd parity for each of the DES key octets comprising the | |||

Three-Key Triple-DES key that is to be wrapped, call the result | Three-Key Triple-DES key that is to be wrapped, call the result | |||

CEK. | CEK. | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note: When the same Three-Key Triple-DES key is wrapped in different | Note: When the same Three-Key Triple-DES key is wrapped in different | |||

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

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

3.2 Triple-DES Key Unwrap | 3.2 Triple-DES Key Unwrap | |||

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

Triple-DES key-encryption key. The Triple-DES key unwrap algorithm | Triple-DES key-encryption key. The Triple-DES key unwrap algorithm | |||

is: | is: | |||

1. If the wrapped key is not 40 octets, then error. | 1. If the wrapped key is not 40 octets, then error. | |||

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

key. Use an initialization vector (IV) of 0x4adda22c79e82105. | Use an initialization vector (IV) of 0x4adda22c79e82105. Call the | |||

Call the output TEMP3. | output TEMP3. | |||

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

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

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

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

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

32 octets. | octets. | |||

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

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

Call the ciphertext CEKICV. | Call the ciphertext CEKICV. | |||

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

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

8 octets. | octets. | |||

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

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

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

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

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

9. Use CEK as a Triple-DES key. | 9. Use CEK as a Triple-DES key. | |||

3.3 Triple-DES Key Wrap Algorithm Identifier | 3.3 Triple-DES Key Wrap Algorithm Identifier | |||

Some security protocols employ ASN.1 [X.208-88, X.209-88], and these | Some security protocols employ ASN.1 [X.208-88, X.209-88], and these | |||

protocols employ algorithm identifiers to name cryptographic | protocols employ algorithm identifiers to name cryptographic | |||

algorithms. To support these protocols, the Triple-DES key wrap | algorithms. To support these protocols, the Triple-DES key wrap | |||

algorithm has been assigned the following algorithm identifier: | algorithm has been assigned the following algorithm identifier: | |||

skipping to change at page 4, line 36 | skipping to change at page 4, line 17 | |||

This section contains a Triple-DES Key Wrap example. Intermediate | This section contains a Triple-DES Key Wrap example. Intermediate | |||

values corresponding to the named items in section 3.1 are given in | values corresponding to the named items in section 3.1 are given in | |||

hexadecimal. | hexadecimal. | |||

CEK: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 | CEK: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 | |||

KEK: 255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838 251f | KEK: 255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838 251f | |||

ICV: 181b 7e96 86e0 4a4e | ICV: 181b 7e96 86e0 4a4e | |||

CEKICV: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 | CEKICV: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 | |||

181b 7e96 86e0 4a4e | 181b 7e96 86e0 4a4e | |||

IV: 5dd4 cbfc 96f5 453b | IV: 5dd4 cbfc 96f5 453b | |||

TEMP1: cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 3b97 7a79 60f6 | TEMP1: cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 973b 7a79 60f6 | |||

a44d cc5f 729d 8449 | a44d cc5f 729d 8449 | |||

TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 | TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 | |||

5c1f 3b97 7a79 60f6 a44d cc5f 729d 8449 | 5c1f 973b 7a79 60f6 a44d cc5f 729d 8449 | |||

TEMP3: 4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4 | TEMP3: 4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4 | |||

2add 75c6 89a7 c1cf 3b45 f596 fccb d45d | 2add 75c6 89a7 c1cf 3b45 f596 fccb d45d | |||

RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403 | RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403 | |||

7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4 | 7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4 | |||

4 RC2 Key Wrapping and Unwrapping | 4 RC2 Key Wrapping and Unwrapping | |||

This section specifies the algorithms for wrapping and unwrapping one | This section specifies the algorithms for wrapping and unwrapping one | |||

RC2 key with another RC2 key [RC2]. | RC2 key with another RC2 key [RC2]. | |||

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

4.1 RC2 Key Wrap | 4.1 RC2 Key Wrap | |||

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

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

1. Let the RC2 key be called CEK, and let the length of CEK in | 1. Let the RC2 key be called CEK, and let the length of CEK in | |||

octets be called LENGTH. LENGTH is a single octet. | octets be called LENGTH. LENGTH is a single octet. | |||

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

3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple | 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 | of 8, the PAD has a length of zero. If the length of LCEK is not | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

keys, a fresh initialization vector (IV) must be generated for each | keys, a fresh initialization vector (IV) must be generated for each | |||

invocation of the key wrap algorithm. | invocation of the key wrap algorithm. | |||

4.2 RC2 Key Unwrap | 4.2 RC2 Key Unwrap | |||

The RC2 key unwrap algorithm decrypts a RC2 key using a RC2 key- | The RC2 key unwrap algorithm decrypts a RC2 key using a RC2 key- | |||

encryption key. The RC2 key unwrap algorithm is: | encryption key. The RC2 key unwrap algorithm is: | |||

1. If the wrapped key is not a multiple of 8 octets, then error. | 1. If the wrapped key is not a multiple of 8 octets, then error. | |||

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

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

the output TEMP3. | the output TEMP3. | |||

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

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

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

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

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

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

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

Call the plaintext LCEKPADICV. | Call the plaintext LCEKPADICV. | |||

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

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

remaining octets. | octets. | |||

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

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

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

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

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

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

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

10. Use CEK as an RC2 key. | 10. Use CEK as an RC2 key. | |||

4.3 RC2 Key Wrap Algorithm Identifier | 4.3 RC2 Key Wrap Algorithm Identifier | |||

Some security protocols employ ASN.1 [X.208-88, X.209-88], and these | Some security protocols employ ASN.1 [X.208-88, X.209-88], and these | |||

protocols employ algorithm identifiers to name cryptographic | protocols employ algorithm identifiers to name cryptographic | |||

skipping to change at page 6, line 38 | skipping to change at page 6, line 21 | |||

RC2ParameterVersion ::= INTEGER | RC2ParameterVersion ::= INTEGER | |||

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

3.4 RC2 Key Wrap Example | 4.4 RC2 Key Wrap Example | |||

This section contains a RC2 Key Wrap example. Intermediate values | This section contains a RC2 Key Wrap example. Intermediate values | |||

corresponding to the named items in section 4.1 are given in | corresponding to the named items in section 4.1 are given in | |||

hexadecimal. | hexadecimal. | |||

CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9 | CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9 | |||

KEK: fd04 fd08 0607 07fb 0003 feff fd02 fe05 | KEK: fd04 fd08 0607 07fb 0003 feff fd02 fe05 | |||

LENGTH: 10 | LENGTH: 10 | |||

LCEK: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9 | LCEK: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9 | |||

PAD: 4845 cce7 fd12 50 | PAD: 4845 cce7 fd12 50 | |||

skipping to change at page 7, line 19 | skipping to change at page 7, line 5 | |||

TEMP2: c7d9 0059 b29e 97f7 a01d a259 3793 1260 | TEMP2: c7d9 0059 b29e 97f7 a01d a259 3793 1260 | |||

e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932 | e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932 | |||

9fa9 8a07 a31f f7a7 | 9fa9 8a07 a31f f7a7 | |||

TEMP3: a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac | TEMP3: a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac | |||

b870 ce04 f555 8ce4 6012 9337 59a2 1da0 | b870 ce04 f555 8ce4 6012 9337 59a2 1da0 | |||

f797 9eb2 5900 d9c7 | f797 9eb2 5900 d9c7 | |||

RESULT: 70e6 99fb 5701 f783 3330 fb71 e87c 85a4 | RESULT: 70e6 99fb 5701 f783 3330 fb71 e87c 85a4 | |||

20bd c99a f05d 22af 5a0e 48d3 5f31 3898 | 20bd c99a f05d 22af 5a0e 48d3 5f31 3898 | |||

6cba afb4 b28d 4f35 | 6cba afb4 b28d 4f35 | |||

References | 5 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 2630, | [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, | |||

June 1999. | June 1999. | |||

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

RFC 2631. June 1999. | 2631, June 1999. | |||

DSS National Institute of Standards and Technology. | [DSS] National Institute of Standards and Technology. FIPS Pub | |||

FIPS Pub 186: Digital Signature Standard. 19 May 1994. | 186: Digital Signature Standard. 19 May 1994. | |||

MODES National Institute of Standards and Technology. | [MODES] National Institute of Standards and Technology. FIPS Pub | |||

FIPS Pub 81: DES Modes of Operation. 2 December 1980. | 81: DES Modes of Operation. 2 December 1980. | |||

RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness | [RANDOM] Eastlake, D., Crocker, S. 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 | |||

RFC 2268. March 1998. | Algorithm", RFC 2268, March 1998. | |||

SHA1 National Institute of Standards and Technology. | [SHA1] National Institute of Standards and Technology. FIPS Pub | |||

FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. | 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", BCP 14, RFC 2119, March 1997. | |||

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

Rules for Abstract Syntax Notation One (ASN.1). 1988. | Encoding Rules for Abstract Syntax Notation One (ASN.1). | |||

1988. | ||||

Security Considerations | 6 Security Considerations | |||

Implementations must protect the key-encryption key. Compromise of | Implementations must protect the key-encryption key. Compromise of | |||

the key-encryption key may result in the disclosure of all keys that | the key-encryption key may result in the disclosure of all keys that | |||

have been wrapped with the key-encryption key, which may lead to the | have been wrapped with the key-encryption key, which may lead to the | |||

disclosure of all traffic protected with those wrapped key. | disclosure of all traffic protected with those wrapped key. | |||

Implementations must randomly generate initialization vectors (IVs) | Implementations must randomly generate initialization vectors (IVs) | |||

and padding. The generation of quality random numbers is difficult. | and padding. The generation of quality random numbers is difficult. | |||

RFC 1750 [RANDOM] offers important guidance in this area, and | RFC 1750 [RANDOM] offers important guidance in this area, and | |||

Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique. | Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique. | |||

skipping to change at page 8, line 41 | skipping to change at page 8, line 35 | |||

decrypt the content. Therefore, implementers must ensure that key- | decrypt the content. 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. | encryption algorithms. | |||

These key wrap algorithms specified in this document have been | These key wrap algorithms specified in this document have been | |||

reviewed for use with Triple-DES and RC2, and they have not been | reviewed for use with Triple-DES and RC2, and they have not been | |||

reviewed for use with other encryption algorithms. Similarly, the | reviewed for use with other encryption algorithms. Similarly, the | |||

key wrap algorithms make use of CBC mode [MODES], and they have not | key wrap algorithms make use of CBC mode [MODES], and they have not | |||

been reviewed for use with other cryptographic modes. | been reviewed for use with other cryptographic modes. | |||

Acknowledgments | 7 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 Carl Ellison, Peter Gutmann, Bob | Group. I extend a special thanks to Carl Ellison, Peter Gutmann, Bob | |||

Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for | Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for | |||

their support in defining these algorithms and generating this | their support in defining these algorithms and generating this | |||

specification. | specification. | |||

Author Address | 8 Author Address | |||

Russell Housley | Russell Housley | |||

RSA Laboratories | RSA Laboratories | |||

918 Spring Knoll Drive | 918 Spring Knoll Drive | |||

Herndon, VA 20170 | Herndon, VA 20170 | |||

USA | USA | |||

rhousley@rsasecurity.com | EMail: rhousley@rsasecurity.com | |||

Full Copyright Statement | 9 Full Copyright Statement | |||

Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2001). All Rights Reserved. | |||

This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||

others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||

or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||

and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||

kind, provided that the above copyright notice and this paragraph are | kind, provided that the above copyright notice and this paragraph are | |||

included on all such copies and derivative works. In addition, the | included on all such copies and derivative works. However, this | |||

ASN.1 module presented in Appendix A may be used in whole or in part | document itself may not be modified in any way, such as by removing | |||

without inclusion of the copyright notice. However, this document | the copyright notice or references to the Internet Society or other | |||

itself may not be modified in any way, such as by removing the | ||||

copyright notice or references to the Internet Society or other | ||||

Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||

developing Internet standards in which case the procedures for | developing Internet standards in which case the procedures for | |||

copyrights defined in the Internet Standards process shall be | copyrights defined in the Internet Standards process must be | |||

followed, or as required to translate it into languages other than | followed, or as required to translate it into languages other than | |||

English. | English. | |||

The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||

revoked by the Internet Society or its successors or assigns. This | revoked by the Internet Society or its successors or assigns. | |||

document and the information contained herein is provided on an "AS | ||||

IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK | This document and the information contained herein is provided on an | |||

FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||

LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||

NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |||

OR FITNESS FOR A PARTICULAR PURPOSE. | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||

Acknowledgement | ||||

Funding for the RFC Editor function is currently provided by the | ||||

Internet Society. | ||||

End of changes. | ||||

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