draft-ietf-smime-hmac-key-wrap-02.txt   rfc3537.txt 
S/MIME Working Group J. Schaad Network Working Group J. Schaad
Internet Draft Soaring Hawk Consulting Request for Comments: 3537 Soaring Hawk Consulting
draft-ietf-smime-hmac-key-wrap-02.txt R. Housley Category: Standards Track R. Housley
Category: Standards Vigil Security Vigil Security
February 2003 May 2003
Wrapping an HMAC key with a Triple-DES Key or an AES Key Wrapping a Hashed Message Authentication Code (HMAC) key
with a Triple-Data Encryption Standard (DES) Key
or an Advanced Encryption Standard (AES) Key
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of [RFC2026]. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- Copyright (C) The Internet Society (2003). All Rights Reserved.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines two methods for wrapping an HMAC (Hashed This document defines two methods for wrapping an HMAC (Hashed
Message Authentication Code) key. The first method defined uses a Message Authentication Code) key. The first method defined uses a
Triple DES (Data Encryption Standard) key to encrypt the HMAC key. Triple DES (Data Encryption Standard) key to encrypt the HMAC key.
The second method defined uses an AES (Advanced Encryption Standard) The second method defined uses an AES (Advanced Encryption Standard)
key to encrypt the HMAC key. One place that such an algorithm is key to encrypt the HMAC key. One place that such an algorithm is
used is for the Authenticated Data type in CMS (Cryptographic used is for the Authenticated Data type in CMS (Cryptographic Message
Message Syntax). Syntax).
1. Introduction 1. Introduction
Standard methods exist for encrypting a Triple-DES (3DES) content- Standard methods exist for encrypting a Triple-DES (3DES) content-
encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES- encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES-
WRAP] and for encrypting an AES CEK with an AES KEK [AES-WRAP]. WRAP], and for encrypting an AES CEK with an AES KEK [AES-WRAP].
Triple-DES key wrap imposes parity restrictions, and in both Triple-DES key wrap imposes parity restrictions, and in both
instances there are restrictions on the size of the key being instances there are restrictions on the size of the key being wrapped
wrapped that make the encryption of HMAC [HMAC] keying material that make the encryption of HMAC [HMAC] keying material difficult.
difficult.
This document specifies a mechanism for the encryption of an HMAC
key of arbitrary length by a 3DES KEK or an AES KEK.
Schaad & Housley Standards - July 2002 1 This document specifies a mechanism for the encryption of an HMAC key
HMAC Key Wrap February 2002 of arbitrary length by a 3DES KEK or an AES KEK.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS]. document are to be interpreted as described in BCP 14, RFC 2119
[STDWORDS].
2. HMAC Key Guidelines 2. HMAC Key Guidelines
[HMAC] suggests that the key be at least as long as the output (L) [HMAC] suggests that the key be at least as long as the output (L) of
of the hash function being used. When keys longer than the block the hash function being used. When keys longer than the block size
size of the hash algorithm are used, they are hashed and the of the hash algorithm are used, they are hashed and the resulting
resulting hash value is used. Using keys much longer than L hash value is used. Using keys much longer than L provides no
provides no security benefit, unless the random function used to security benefit, unless the random function used to create the key
create the key has low entropy output. has low entropy output.
3. HMAC Key Wrapping and Unwrapping with Triple-DES 3. HMAC Key Wrapping and Unwrapping with Triple-DES
This section specifies the algorithms for wrapping and unwrapping an This section specifies the algorithms for wrapping and unwrapping an
HMAC key with a 3DES KEK [3DES]. HMAC key with a 3DES KEK [3DES].
The 3DES wrapping of HMAC keys is based on the algorithm defined in The 3DES wrapping of HMAC keys is based on the algorithm defined in
Section 3 of [3DES-WRAP]. The major differences are due to the fact Section 3 of [3DES-WRAP]. The major differences are due to the fact
that an HMAC key is variable length and the HMAC key has no that an HMAC key is of variable length and the HMAC key has no
particular parity. particular parity.
In the algorithm description, "a || b" is used to represent 'a' In the algorithm description, "a || b" is used to represent 'a'
concatenated with 'b'. concatenated with 'b'.
3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key 3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key
This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm
is: is:
skipping to change at line 87 skipping to change at page 2, line 39
In the algorithm description, "a || b" is used to represent 'a' In the algorithm description, "a || b" is used to represent 'a'
concatenated with 'b'. concatenated with 'b'.
3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key 3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key
This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm
is: is:
1. Let the HMAC key be called KEY, and let the length of KEY in 1. Let the HMAC key be called KEY, and let the length of KEY in
octets be called LENGTH. LENGTH is a single octet. octets be called LENGTH. LENGTH is a single octet.
2. Let LKEY = LENGTH || KEY. 2. Let LKEY = LENGTH || KEY.
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple 3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple
of 8, the PAD has a length of zero. If the length of LKEY is of 8, the PAD has a length of zero. If the length of LKEY 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 LKEYPAD a multiple of 8. octets to make the length of LKEYPAD a multiple of 8.
4. Compute an 8 octet key checksum value on LKEYPAD as described
in Section 2 of [3DES-WRAP], call the result ICV. 4. Compute an 8 octet key checksum value on LKEYPAD as described in
Section 2 of [3DES-WRAP], call the result ICV.
5. Let LKEYPADICV = LKEYPAD || ICV. 5. Let LKEYPADICV = LKEYPAD || ICV.
6. Generate 8 octets at random, call the result IV. 6. Generate 8 octets at random, call the result IV.
7. Encrypt LKEYPADICV in CBC mode using the 3DES KEK.
Use the random value generated in the previous step as the 7. Encrypt LKEYPADICV in CBC mode using the 3DES KEK. Use the
initialization vector (IV). Call the ciphertext TEMP1. random value generated in the previous step as the 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 3DES KEK. Use
an initialization vector (IV) of 0x4adda22c79e82105.
Schaad & Housley Standards - July 2002 2 10. Encrypt TEMP3 in CBC mode using the 3DES KEK. Use an
HMAC Key Wrap February 2002 initialization vector (IV) of 0x4adda22c79e82105.
Note: When the same HMAC key is wrapped in different 3DES KEKs, a Note: When the same HMAC key is wrapped in different 3DES KEKs, a
fresh initialization vector (IV) must be generated for each fresh initialization vector (IV) must be generated for each
invocation of the HMAC key wrap algorithm. invocation of the HMAC key wrap algorithm (step 6).
3.2 Unwrapping an HMAC Key with a Triple-DES Key-Encryption Key 3.2 Unwrapping an HMAC Key with a Triple-DES Key-Encryption Key
This algorithm decrypts an HMAC key using a 3DES KEK. The algorithm This algorithm decrypts an HMAC key using a 3DES KEK. The algorithm
is: 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 3DES KEK.
Use an initialization vector (IV) of 0x4adda22c79e82105. Call 2. Decrypt the wrapped key in CBC mode using the 3DES KEK. Use an
the output TEMP3. initialization vector (IV) of 0x4adda22c79e82105. Call 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 composed of the
5. Decrypt TEMP1 in CBC mode using the 3DES KEK. Use
the IV value from the previous step as the initialization
vector. Call the plaintext LKEYPADICV.
6. Decompose the LKEYPADICV into LKEYPAD, and ICV. ICV is the
least significant (last) octet 8 octets. LKEYPAD is the
remaining octets. remaining octets.
7. Compute an 8 octet key checksum value on LKEYPAD as described
in Section 2 of [3DES-WRAP]. If the computed key checksum value 5. Decrypt TEMP1 in CBC mode using the 3DES KEK. Use the IV value
does not match the decrypted key checksum value, ICV, then from the previous step as the initialization vector. Call the
error. plaintext LKEYPADICV.
6. Decompose the LKEYPADICV into LKEYPAD, and ICV. ICV is the least
significant (last) 8 octets. LKEYPAD is composed of the
remaining octets.
7. Compute an 8 octet key checksum value on LKEYPAD as described in
Section 2 of [3DES-WRAP]. If the computed key checksum value
does not match the decrypted key checksum value, ICV, then error.
8. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the 8. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the
most significant (first) octet. KEY is the following LENGTH most significant (first) octet. KEY is the following LENGTH of
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 KEY as an HMAC key. 10. Use KEY as an HMAC key.
3.3 HMAC Key Wrap with Triple-DES Algorithm Identifier 3.3 HMAC Key Wrap with Triple-DES 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 HMAC Key Wrap with algorithms. To support these protocols, the HMAC Key Wrap with
Triple-DES algorithm has been assigned the following algorithm Triple-DES algorithm has been assigned the following algorithm
identifier: identifier:
skipping to change at line 161 skipping to change at page 4, line 31
id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1) id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 11 } smime(16) alg(3) 11 }
The AlgorithmIdentifier parameter field MUST be NULL. The AlgorithmIdentifier parameter field MUST be NULL.
3.4 HMAC Key Wrap with Triple-DES Test Vector 3.4 HMAC Key Wrap with Triple-DES Test Vector
KEK : 5840df6e 29b02af1 KEK : 5840df6e 29b02af1
: ab493b70 5bf16ea1 : ab493b70 5bf16ea1
Schaad & Housley Standards - July 2002 3
HMAC Key Wrap February 2002
: ae8338f4 dcc176a8 : ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340 HMAC_KEY : c37b7e64 92584340
: bed12207 80894115 : bed12207 80894115
: 5068f738 : 5068f738
IV : 050d8c79 e0d56b75 IV : 050d8c79 e0d56b75
PAD : 38be62 PAD : 38be62
skipping to change at line 206 skipping to change at page 5, line 23
: dc161118 601f2863 : dc161118 601f2863
: e2929b3b dd17697c : e2929b3b dd17697c
4. HMAC Key Wrapping and Unwrapping with AES 4. HMAC Key Wrapping and Unwrapping with AES
This section specifies the algorithms for wrapping and unwrapping an This section specifies the algorithms for wrapping and unwrapping an
HMAC key with an AES KEK [AES-WRAP]. HMAC key with an AES KEK [AES-WRAP].
The AES wrapping of HMAC keys is based on the algorithm defined in The AES wrapping of HMAC keys is based on the algorithm defined in
[AES-WRAP]. The major difference is inclusion of padding due to the [AES-WRAP]. The major difference is inclusion of padding due to the
fact that the length of an HMAC key may not be a multiple of 64 fact that the length of an HMAC key may not be a multiple of 64 bits.
bits.
In the algorithm description, "a || b" is used to represent 'a' In the algorithm description, "a || b" is used to represent 'a'
concatenated with 'b'. concatenated with 'b'.
4.1 Wrapping an HMAC Key with an AES Key-Encryption Key 4.1 Wrapping an HMAC Key with an AES Key-Encryption Key
This algorithm encrypts an HMAC key with an AES KEK. The algorithm This algorithm encrypts an HMAC key with an AES KEK. The algorithm
is: is:
1. Let the HMAC key be called KEY, and let the length of KEY in 1. Let the HMAC key be called KEY, and let the length of KEY in
Schaad & Housley Standards - July 2002 4
HMAC Key Wrap February 2002
octets be called LENGTH. LENGTH is a single octet. octets be called LENGTH. LENGTH is a single octet.
2. Let LKEY = LENGTH || KEY. 2. Let LKEY = LENGTH || KEY.
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple 3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple
of 8, the PAD has a length of zero. If the length of LKEY is of 8, the PAD has a length of zero. If the length of LKEY 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 LKEYPAD a multiple of 8. octets to make the length of LKEYPAD a multiple of 8.
4. Encrypt LKEYPAD using the AES key wrap algorithm specified in 4. Encrypt LKEYPAD using the AES key wrap algorithm specified in
section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption
key. The result is 8 octets longer than LKEYPAD. key. The result is 8 octets longer than LKEYPAD.
4.2 Unwrapping an HMAC Key with an AES Key 4.2 Unwrapping an HMAC Key with an AES Key
The AES key unwrap algorithm decrypts an HMAC key using an AES KEK. The AES key unwrap algorithm decrypts an HMAC key using an AES KEK.
The AES key unwrap algorithm is: The AES 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.
skipping to change at line 238 skipping to change at page 6, line 11
4. Encrypt LKEYPAD using the AES key wrap algorithm specified in 4. Encrypt LKEYPAD using the AES key wrap algorithm specified in
section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption
key. The result is 8 octets longer than LKEYPAD. key. The result is 8 octets longer than LKEYPAD.
4.2 Unwrapping an HMAC Key with an AES Key 4.2 Unwrapping an HMAC Key with an AES Key
The AES key unwrap algorithm decrypts an HMAC key using an AES KEK. The AES key unwrap algorithm decrypts an HMAC key using an AES KEK.
The AES key unwrap algorithm is: The AES 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 using the AES key unwrap algorithm 2. Decrypt the wrapped key using the AES key unwrap algorithm
specified in section 2.2.2 of [AES-WRAP], using the AES KEK as specified in section 2.2.2 of [AES-WRAP], using the AES KEK as
the decryption key. If the unwrap algorithm internal integrity the decryption key. If the unwrap algorithm internal integrity
check fails, then error, otherwise call the result LKEYPAD. check fails, then error, otherwise call the result LKEYPAD.
3. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the 3. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the
most significant (first) octet. KEY is the following LENGTH most significant (first) octet. KEY is the following LENGTH of
octets. PAD is the remaining octets, if any. octets. PAD is the remaining octets, if any.
4. If the length of PAD is more than 7 octets, then error. 4. If the length of PAD is more than 7 octets, then error.
5. Use KEY as an HMAC key. 5. Use KEY as an HMAC key.
4.3 HMAC Key Wrap with AES Algorithm Identifier 4.3 HMAC Key Wrap with AES 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 HMAC Key Wrap with AES algorithms. To support these protocols, the HMAC Key Wrap with AES
algorithm has been assigned the following algorithm identifier: algorithm has been assigned the following algorithm identifier:
id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1) id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1)
skipping to change at line 275 skipping to change at page 6, line 52
: ae8338f4 dcc176a8 : ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340 HMAC_KEY : c37b7e64 92584340
: bed12207 80894115 : bed12207 80894115
: 5068f738 : 5068f738
PAD : 050d8c PAD : 050d8c
LKEYPAD : 14c37b7e 64925843 LKEYPAD : 14c37b7e 64925843
: 40bed122 07808941 : 40bed122 07808941
Schaad & Housley Standards - July 2002 5
HMAC Key Wrap February 2002
: 155068f7 38050d8c : 155068f7 38050d8c
Wrapped Key : 9fa0c146 5291ea6d Wrapped Key : 9fa0c146 5291ea6d
: b55360c6 cb95123c : b55360c6 cb95123c
: d47b38cc e84dd804 : d47b38cc e84dd804
: fbcec5e3 75c3cb13 : fbcec5e3 75c3cb13
5. Security Considerations 5. Security Considerations
Implementations must protect the key-encryption key (KEK). Implementations must protect the key-encryption key (KEK).
Compromise of the KEK may result in the disclosure of all HMAC keys Compromise of the KEK may result in the disclosure of all HMAC keys
that have been wrapped with the KEK, which may lead to loss of data that have been wrapped with the KEK, which may lead to loss of data
skipping to change at line 298 skipping to change at page 7, line 21
Implementations must protect the key-encryption key (KEK). Implementations must protect the key-encryption key (KEK).
Compromise of the KEK may result in the disclosure of all HMAC keys Compromise of the KEK may result in the disclosure of all HMAC keys
that have been wrapped with the KEK, which may lead to loss of data that have been wrapped with the KEK, which may lead to loss of data
integrity protection. integrity protection.
The use of these key wrap functions provide confidentiality and data The use of these key wrap functions provide confidentiality and data
integrity, but they do not necessarily provide data origination integrity, but they do not necessarily provide data origination
authentication. Anyone possessing the KEK can create a message that authentication. Anyone possessing the KEK can create a message that
passes the integrity check. If data origination authentication is passes the integrity check. If data origination authentication is
also desired, then the KEK distribution mechanism must provide data also desired, then the KEK distribution mechanism must provide data
origin authentication of the KEK. Alternatively, a digital origin authentication of the KEK. Alternatively, a digital signature
signature may be used. may be used.
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 Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
technique.
The key wrap algorithms specified in this document have been The key wrap algorithms specified in this document have been reviewed
reviewed for use with Triple-DES and AES, and they have not been for use with Triple-DES and AES, and have not been reviewed for use
reviewed for use with other encryption algorithms. with other encryption algorithms.
6. References 6. References
This section provides normative and informative references.
6.1 Normative References 6.1 Normative 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. Triple Data Encryption Algorithm Modes of Operation.
1998. 1998.
3DES-WRAP Housley, R., Triple-DES and RC2 Key Wrapping. RFC 3217. [3DES-WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001. December 2001.
AES National Institute of Standards and Technology. [AES] National Institute of Standards and Technology. FIPS Pub
FIPS Pub 197: Advanced Encryption Standard (AES). 197: Advanced Encryption Standard (AES). 26 November
26 November 2001. 2001.
AES-WRAP Schaad, J., R. Housley, Advanced Encryption Standard (AES)
Key Wrap Algorithm, RFC 3394, September 2002.
HMAC Krawczyk, H., M. Bellare, and R. Canetti. HMAC: Keyed-
Schaad & Housley Standards - July 2002 6 [AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard
HMAC Key Wrap February 2002 (AES) Key Wrap Algorithm", RFC 3394, September 2002.
Hashing for Message Authentication. RFC 2104. [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
February 1997. Hashing for Message Authentication", RFC 2104, February
1997.
STDWORDS Bradner, S., "Key words for use in RFCs to Indicate [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2 Informative References 6.2 Informative References
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.
RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness [RANDOM] Eastlake 3rd, D., Crocker, S. and J. Schiller,
Recommendations for Security. RFC 1750. December 1994. "Randomness Recommendations for Security", RFC 1750,
December 1994.
RFC2026 Bradner, S., "The Internet Standards Process - Revision [RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
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 [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988. 1988.
7. Author's Addresses 7. Authors' Addresses
Jim Schaad Jim Schaad
Soaring Hawk Consulting Soaring Hawk Consulting
Email: jimsch@exmsft.com EMail: jimsch@exmsft.com
Russell Housley Russell Housley
Vigil Security Vigil Security
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
Email: housley@vigilsec.com EMail: housley@vigilsec.com
Schaad & Housley Standards - July 2002 7
HMAC Key Wrap February 2002
Full Copyright Statement 8. Full Copyright Statement
"Copyright (C) The Internet Society 2002. All Rights Reserved. Copyright (C) The Internet Society (2003). 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 kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other 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 must 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. revoked by the Internet Society or its successors or assignees.
Schaad & Housley Standards - July 2002 8 This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
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/