idnits 2.17.1 draft-ietf-smime-cms-rsa-kem-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 306 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2009) is 5407 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3217 (ref. '3DES-WRAP') ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. 'AES-WRAP') ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' ** Obsolete normative reference: RFC 3851 (ref. 'MSG') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3447 (ref. 'PKCS1') (Obsoleted by RFC 8017) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group James Randall, Randall Consulting 3 Internet Draft Burt Kaliski, EMC 4 John Brainard, RSA 5 Sean Turner, IECA 6 Expires: January 7, 2010 Category: Standards 7 July 7, 2009 9 Use of the RSA-KEM Key Transport Algorithm in CMS 10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that other 45 groups may also distribute working documents as Internet-Drafts. 47 This Internet-Draft will expire on January 6, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your 58 rights and restrictions with respect to this document. 60 Comments or suggestions for improvement may be made on the "ietf- 61 smime" mailing list, or directly to the authors. 63 Abstract 65 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 66 mechanism for transporting keying data to a recipient using the 67 recipient's RSA public key. This document specifies the conventions 68 for using the RSA-KEM Key Transport Algorithm with the Cryptographic 69 Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and 70 ISO/IEC 18033-2. 72 Conventions Used in This Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [STDWORDS]. 78 1. Introduction 80 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 81 mechanism for transporting keying data to a recipient using the 82 recipient's RSA public key. 84 Most previous key transport algorithms based on the RSA public-key 85 cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have 86 the following general form: 88 1. Format or "pad" the keying data to obtain an integer m. 90 2. Encrypt the integer m with the recipient's RSA public key: 92 c = m^e mod n 94 3. Output c as the encrypted keying data. 96 The RSA-KEM Key Transport Algorithm takes a different approach that 97 provides higher security assurance, by encrypting a _random_ integer 98 with the recipient's public key, and using a symmetric key-wrapping 99 scheme to encrypt the keying data. It has the following form: 101 1. Generate a random integer z between 0 and n-1. 103 2. Encrypt the integer z with the recipient's RSA public key: 105 c = z^e mod n 107 3. Derive a key-encrypting key KEK from the integer z. 109 4. Wrap the keying data using KEK to obtain wrapped keying data WK. 111 5. Output c and WK as the encrypted keying data. 113 This different approach provides higher security assurance because 114 (a) the input to the underlying RSA operation is effectively a random 115 integer between 0 and n-1, where n is the RSA modulus, so it does not 116 have any structure that could be exploited by an adversary, and (b) 117 the input is independent of the keying data so the result of the RSA 118 decryption operation is not directly available to an adversary. As a 119 result, the algorithm enjoys a "tight" security proof in the random 120 oracle model. (In other padding schemes, such as PKCS #1 v1.5, the 121 input has structure and/or depends on the keying data, and the 122 provable security assurances are not as strong.) The approach is also 123 architecturally convenient because the public-key operations are 124 separate from the symmetric operations on the keying data. One 125 benefit is that the length of the keying data is bounded only by the 126 symmetric key-wrapping scheme, not the size of the RSA modulus. 128 The RSA-KEM Key Transport Algorithm in various forms is being adopted 129 in several draft standards as well as in ANS-X9.44 and ISO/IEC 18033- 130 2. It has also been recommended by the NESSIE project [NESSIE]. 132 For completeness, a specification of the algorithm is given in 133 Appendix A of this document; ASN.1 syntax is given in Appendix B. 135 NOTE: The term KEM stands for "key encapsulation mechanism" and 136 refers to the first three steps of the process above. The 137 formalization of key transport algorithms (or more generally, 138 asymmetric encryption schemes) in terms of key encapsulation 139 mechanisms is described further in research by Victor Shoup leading 140 to the development of the ISO/IEC 18033-2 standard [SHOUP]. 142 2. Use in CMS 144 The RSA-KEM Key Transport Algorithm MAY be employed for one or more 145 recipients in the CMS enveloped-data content type (Section 6 of 146 [CMS]), where the keying data processed by the algorithm is the CMS 147 content-encryption key. 149 The RSA-KEM Key Transport Algorithm SHOULD be considered for new 150 CMS-based applications as a replacement for the widely implemented 151 RSA encryption algorithm specified originally in PKCS #1 v1.5 (see 152 [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to 153 chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm has 154 also been proposed as a replacement (see [PKCS1] and [CMS-OAEP]). 155 RSA-KEM has the advantage over RSAES-OAEP of a tighter security 156 proof, but the disadvantage of slightly longer encrypted keying data. 158 2.1. Underlying Components 160 A CMS implementation that supports the RSA-KEM Key Transport 161 Algorithm MUST support at least the following underlying components: 163 o For the key derivation function, KDF2 (see [ANS-X9.44]) (see 164 [IEEE-P1363a]) based on SHA-1 (see [FIPS-180-2]) (this function is 165 also specified as the key derivation function in [ANS-X9.63]), and 166 KDF3 (see [IEEE-P1363a]) based on SHA-256 (see [FIPS-180-2]). 168 o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap 169 with a 128-bit key encrypting key (see [AES-WRAP]) 171 An implementation SHOULD also support KDF3 based on SHA-1 and KDF2 172 based on SHA-256. The Camellia key wrap algorithm (see [CAMELLIA]) 173 SHOULD be supported, and, if 3DES is supported as a content- 174 encryption cipher, then the Triple-DES Key Wrap (see [3DES-WRAP]) 175 SHOULD also be supported. 177 It MAY support other underlying components. When AES or Camellia are 178 used the data block size is 128 bits while the key size can be 128, 179 192, or 256 bits while Triple DES requires a data block size of 64 180 bits and a key size of 112 or 168 bits. 182 2.2. RecipientInfo Conventions 184 When the RSA-KEM Key Transport Algorithm is employed for a recipient, 185 the RecipientInfo alternative for that recipient MUST be 186 KeyTransRecipientInfo. The algorithm-specific fields of the 187 KeyTransRecipientInfo value MUST have the following values: 189 o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem see Appendix 190 B) 192 o keyEncryptionAlgorithm.parameters MUST be a value of type 193 GenericHybridParameters, identifying the RSA-KEM key encapsulation 194 mechanism (see Appendix B) 196 o encryptedKey MUST be the encrypted keying data output by the 197 algorithm, where the keying data is the content-encryption 198 key.(see Appendix A) 200 2.3. Certificate Conventions 202 The conventions specified in this section augment RFC 3280 [PROFILE]. 204 A recipient who employs the RSA-KEM Key Transport Algorithm MAY 205 identify the public key in a certificate by the same 206 AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using 207 the rsaEncryption object identifier [PKCS1]. The fact that the user 208 will accept RSA-KEM with this public key is not indicated by the use 209 of this identifier. This may be signed by the use of the appropriate 210 SMIME Capabilities either in a message or in the certificate. 212 If the recipient wishes only to employ the RSA-KEM Key Transport 213 Algorithm with a given public key, the recipient MUST identify the 214 public key in the certificate using the id-rsa-kem object identifier 215 (see Appendix B). The parameters are absent. 217 Regardless of the AlgorithmIdentifier used, the RSA public key is 218 encoded in the same manner in the subject public key information. The 219 RSA public key MUST be encoded using the type RSAPublicKey type: 221 RSAPublicKey ::= SEQUENCE { 222 modulus INTEGER, -- n 223 publicExponent INTEGER -- e 224 } 226 Here, the modulus is the modulus n, and publicExponent is the public 227 exponent e. The DER encoded RSAPublicKey is carried in the 228 subjectPublicKey BIT STRING within the subject public key 229 information. 231 The intended application for the key MAY be indicated in the key 232 usage certificate extension (see [PROFILE], Section 4.2.1.3). If the 233 keyUsage extension is present in a certificate that conveys an RSA 234 public key with the id-rsa-kem object identifier as discussed above, 235 then the key usage extension MUST contain the following value: 237 keyEncipherment. 239 dataEncipherment SHOULD NOT be present. That is, a key intended to be 240 employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT 241 also be employed for data encryption or for authentication such as in 242 signatures. Good cryptographic practice employs a given RSA key pair 243 in only one scheme. This practice avoids the risk that vulnerability 244 in one scheme may compromise the security of the other, and may be 245 essential to maintain provable security. 247 2.4. SMIMECapabilities Attribute Conventions 249 RFC 3851 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 250 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 251 used to specify a partial list of algorithms that the software 252 announcing the SMIMECapabilities can support. When constructing a 253 signedData object, compliant software MAY include the 254 SMIMECapabilities signed attribute announcing that it supports the 255 RSA-KEM Key Transport algorithm. 257 The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport 258 Algorithm MUST include the id-rsa-kem object identifier (see Appendix 259 B) in the capabilityID field and MUST include a 260 GenericHybridParameters value in the parameters field identifying the 261 components with which the algorithm is to be employed. 263 The DER encoding of a SMIMECapability SEQUENCE is the same as the DER 264 encoding of an AlgorithmIdentifier. Example DER encodings for typical 265 sets of components are given in Appendix B.4. 267 3. Security Considerations 269 The security of the RSA-KEM Key Transport Algorithm described in this 270 document can be shown to be tightly related to the difficulty of 271 either solving the RSA problem or breaking the underlying symmetric 272 key-wrapping scheme, if the underlying key derivation function is 273 modeled as a random oracle, and assuming that the symmetric key- 274 wrapping scheme satisfies the properties of a data encapsulation 275 mechanism [SHOUP]. While in practice a random-oracle result does not 276 provide an actual security proof for any particular key derivation 277 function, the result does provide assurance that the general 278 construction is reasonable; a key derivation function would need to 279 be particularly weak to lead to an attack that is not possible in the 280 random oracle model. 282 The RSA key size and the underlying components should be selected 283 consistent with the desired symmetric security level for an 284 application. Several security levels have been identified in [NIST- 285 FIPS PUB 800-57]. For brevity, the first three levels are mentioned 286 here: 288 o 80-bit security. The RSA key size SHOULD be at least 1024 bits, 289 the hash function underlying the KDF SHOULD be SHA-1 or above, and 290 the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple- 291 DES Key Wrap, or Camellia Key Wrap. 293 o 112-bit security. The RSA key size SHOULD be at least 2048 bits, 294 the hash function underlying the KDF SHOULD be SHA-224 or above, 295 and the symmetric key-wrapping scheme SHOULD be AES Key Wrap, 296 Triple-DES Key Wrap, or Camellia Key Wrap. 298 o 128-bit security. The RSA key size SHOULD be at least 3072 bits, 299 the hash function underlying the KDF SHOULD be SHA-256 or above, 300 and the symmetric key-wrapping scheme SHOULD be AES Key Wrap or 301 Camellia Key Wrap. 303 Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all 304 three of these levels; the use of AES or Camellia does not require a 305 128-bit security level for other components. 307 Implementations MUST protect the RSA private key and the content- 308 encryption key. Compromise of the RSA private key may result in the 309 disclosure of all messages protected with that key. Compromise of the 310 content-encryption key may result in disclosure of the associated 311 encrypted content. 313 Additional considerations related to key management may be found in 314 [NIST-GUIDELINE]. 316 The security of the algorithm also depends on the strength of the 317 random number generator, which SHOULD have a comparable security 318 level. For further discussion on random number generation, please see 319 [RANDOM]. 321 Implementations SHOULD NOT reveal information about intermediate 322 values or calculations, whether by timing or other "side channels", 323 or otherwise an opponent may be able to determine information about 324 the keying data and/or the recipient's private key. Although not all 325 intermediate information may be useful to an opponent, it is 326 preferable to conceal as much information as is practical, unless 327 analysis specifically indicates that the information would not be 328 useful. 330 Generally, good cryptographic practice employs a given RSA key pair 331 in only one scheme. This practice avoids the risk that vulnerability 332 in one scheme may compromise the security of the other, and may be 333 essential to maintain provable security. While RSA public keys have 334 often been employed for multiple purposes such as key transport and 335 digital signature without any known bad interactions, for increased 336 security assurance, such combined use of an RSA key pair is NOT 337 RECOMMENDED in the future (unless the different schemes are 338 specifically designed to be used together). 340 Accordingly, an RSA key pair used for the RSA-KEM Key Transport 341 Algorithm SHOULD NOT also be used for digital signatures. (Indeed, 342 ASC X9 requires such a separation between key establishment key pairs 343 and digital signature key pairs.) Continuing this principle of key 344 separation, a key pair used for the RSA-KEM Key Transport Algorithm 345 SHOULD NOT be used with other key establishment schemes, or for data 346 encryption, or with more than one set of underlying algorithm 347 components. 349 Parties MAY formalize the assurance that one another's 350 implementations are correct through implementation validation, e.g. 351 NIST's Cryptographic Module Validation Program (CMVP). 353 4. References 355 4.1. Normative References 357 [3DES-WRAP] Housley, R. Triple-DES and RC2 Key Wrapping. RFC 358 3217. December 2001. 360 [AES-WRAP] Schaad, J. and R. Housley. Advanced Encryption 361 Standard (AES) Key Wrap Algorithm. RFC 3394. 362 September 2002. 364 [ANS-X9.63] American National Standard X9.63-2002: Public Key 365 Cryptography for the Financial Services Industry: 366 Key Agreement and Key Transport Using Elliptic 367 Curve Cryptography. 369 [CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the 370 Camellia Encryption Algorithm in Cryptographic 371 Message Syntax. RFC 3657. December 2005. 373 [CMS] Housley, R. Cryptographic Message Syntax. RFC 374 3852. July 2004. 376 [CMSALGS] Housley, R. Cryptographic Message Syntax (CMS) 377 Algorithms. RFC 3370. August 2002. 379 [FIPS-180-2] National Institute of Standards and Technology 380 (NIST). FIPS 180-2: Secure Hash Standard. August 381 2002. 383 [MSG] Ramsdell, B. S/MIME Version 3 Message 384 Specification. RFC 3851. July 2004. 386 [PROFILE] Cooper, D., Santesson, S., Farrell, S., 387 Boeyen, S., Housley, R., and W. Polk. Internet 388 X.509 Public Key Infrastructure Certificate 389 and Certificate Revocation List (CRL) Profile. 390 RFC 5280. May 2008. 392 [STDWORDS] Bradner, S. Key Words for Use in RFCs to Indicate 393 Requirement Levels. RFC 2119. March 1997. 395 4.2. Informative References 397 [ANS-X9.44] ASC X9F1 Working Group. American National 398 Standard X9.44: Public Key Cryptography for the 399 Financial Services Industry -- Key Establishment 400 Using Integer Factorization Cryptography. 2007 402 [CMS-OAEP] Housley, R. Use of the RSAES-OAEP Key Transport 403 Algorithm in the Cryptographic Message Syntax 404 (CMS). RFC 3560. July 2003. 406 [IEEE-P1363a] IEEE Std 1363a-2004: Standard Specifications for 407 Public Key Cryptography: Additional Techniques. 408 IEEE, 2004. 410 [ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology -- 411 Security techniques -- Encryption algorithms -- 412 Part 2: Asymmetric Ciphers. ISO/IEC, 2005. 414 [NESSIE] NESSIE Consortium. Portfolio of Recommended 415 Cryptographic Primitives. February 27, 2003. 416 Available via http://www.cryptonessie.org/. 418 [NIST-GUIDELINE] National Institute of Standards and Technology. 419 Special Publication 800-57: Recommendation for 420 Key Management. Part 1: General Guideline. 421 August 2005. Available via: 422 http://csrc.nist.gov/publications/index.html. 424 [PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA 425 Cryptography Specifications Version 2.1. RFC 426 3447. February 2003. 428 [RANDOM] Eastlake, D., S. Crocker, and J. Schiller. 429 Randomness Recommendations for Security. RFC 430 4086. June 2005. 432 [SHOUP] Shoup, V. A Proposal for an ISO Standard for 433 Public Key Encryption. Version 2.1, December 20, 434 2001. Available via http://www.shoup.net/papers/. 436 Appendix A. 437 RSA-KEM Key Transport Algorithm 439 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 440 mechanism for transporting keying data to a recipient using the 441 recipient's RSA public key. 443 With this type of algorithm, a sender encrypts the keying data using 444 the recipient's public key to obtain encrypted keying data. The 445 recipient decrypts the encrypted keying data using the recipient's 446 private key to recover the keying data. 448 A.1. Underlying Components 450 The algorithm has the following underlying components: 452 o KDF, a key derivation function, which derives keying data of a 453 specified length from a shared secret value 455 o Wrap, a symmetric key-wrapping scheme, which encrypts keying Data 456 using a key-encrypting key 458 In the following, kekLen denotes the length in bytes of the key- 459 encrypting key for the underlying symmetric key-wrapping scheme. 461 In this scheme, the length of the keying data to be transported MUST 462 be among the lengths supported by the underlying symmetric key- 463 wrapping scheme. (Both the AES and Camellia Key Wraps, for instance, 464 require the length of the keying data to be a multiple of 8 bytes, 465 and at least 16 bytes.) Usage and formatting of the keying data 466 (e.g., parity adjustment for Triple-DES keys) is outside the scope of 467 this algorithm. With some key derivation functions, it is possible to 468 include other information besides the shared secret value in the 469 input to the function. Also, with some symmetric key-wrapping 470 schemes, it is possible to associate a label with the keying data. 471 Such uses are outside the scope of this document, as they are not 472 directly supported by CMS. 474 A.2. Sender's Operations 476 Let (n,e) be the recipient's RSA public key (see [PKCS1] for 477 details) and let K be the keying data to be transported. 479 Let nLen denote the length in bytes of the modulus n, i.e., the least 480 integer such that 2^{8*nLen} > n. 482 The sender performs the following operations: 484 1. Generate a random integer z between 0 and n-1 (see Note), and 485 convert z to a byte string Z of length nLen, most significant byte 486 first: 488 z = RandomInteger (0, n-1) 489 Z = IntegerToString (z, nLen) 491 2. Encrypt the random integer z using the recipient's public key n,e) 492 and convert the resulting integer c to a ciphertext C, a byte 493 string of length nLen: 495 c = z^e mod n 496 C = IntegerToString (c, nLen) 498 3. Derive a key-encrypting key KEK of length kekLen bytes from the 499 byte string Z using the underlying key derivation function: 501 KEK = KDF (Z, kekLen) 503 4. Wrap the keying data K with the key-encrypting key KEK using the 504 underlying key-wrapping scheme to obtain wrapped keying data WK: 506 WK = Wrap (KEK, K) 508 5. Concatenate the ciphertext C and the wrapped keying data WK to 509 obtain the encrypted keying data EK: 511 EK = C || WK 513 6. Output the encrypted keying data EK. 515 NOTE: The random integer z MUST be generated independently at random 516 for different encryption operations, whether for the same or 517 different recipients. 519 A.3. Recipient's Operations 521 Let (n,d) be the recipient's RSA private key (see [PKCS1]; other 522 private key formats are allowed) and let EK be the encrypted keying 523 data. 525 Let nLen denote the length in bytes of the modulus n. 527 The recipient performs the following operations: 529 1. Separate the encrypted keying data EK into a ciphertext C of 530 length nLen bytes and wrapped keying data WK: 532 C || WK = EK 534 If the length of the encrypted keying data is less than nLen 535 bytes, output "decryption error" and stop. 537 2. Convert the ciphertext C to an integer c, most significant byte 538 first. Decrypt the integer c using the recipient's private key 539 (n,d) to recover an integer z (see Note): 541 c = StringToInteger (C) 542 z = c^d mod n 544 If the integer c is not between 0 and n-1, output "decryption 545 error" and stop. 547 3. Convert the integer z to a byte string Z of length nLen, most 548 significant byte first (see Note): 550 Z = IntegerToString (z, nLen) 552 4. Derive a key-encrypting key KEK of length kekLen bytes from 553 the byte string Z using the underlying key derivation function 554 (see Note): 556 KEK = KDF (Z, kekLen) 558 5. Unwrap the wrapped keying data WK with the key-encrypting key 559 KEK using the underlying key-wrapping scheme to recover the 560 keying data K: 562 K = Unwrap (KEK, WK) 564 If the unwrapping operation outputs an error, output "decryption 565 error" and stop. 567 6. Output the keying data K. 569 NOTE: Implementations SHOULD NOT reveal information about the integer 570 z and the string Z, nor about the calculation of the exponentiation 571 in Step 2, the conversion in Step 3, or the key derivation in Step 4, 572 whether by timing or other "side channels". The observable behavior 573 of the implementation SHOULD be the same at these steps for all 574 ciphertexts C that are in range. (For example, IntegerToString 575 conversion should take the same amount of time regardless of the 576 actual value of the integer z.) The integer z, the string Z and other 577 intermediate results MUST be securely deleted when they are no longer 578 needed. 580 Appendix B. 581 ASN.1 Syntax 583 The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm 584 is an extension of the syntax for the "generic hybrid cipher" in 585 ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in ANS 586 X9.44 [ANS-X9.44]. The syntax for the scheme is given in Section B.1. 587 The syntax for selected underlying components including those 588 mentioned above is given in B.2. 590 The following object identifier prefixes are used in the definitions 591 below: 593 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 595 nistAlgorithm OID ::= { 596 joint-iso-itu-t(2) country(16) us(840) organization(1) 597 gov(101) csor(3) nistAlgorithm(4) 598 } 600 pkcs-1 OID ::= { 601 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 602 } 604 NullParms is a more descriptive synonym for NULL when an algorithm 605 identifier has null parameters: 607 NullParms ::= NULL 609 The material in this Appendix is based on ANS X9.44. 611 B.1 RSA-KEM Key Transport Algorithm 613 The object identifier for the RSA-KEM Key Transport Algorithm is id- 614 rsa-kem, which is defined in the draft as: 616 id-rsa-kem OID ::= { 617 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 618 pkcs-9(9) smime(16) alg(3) TBA 619 } 621 When id-rsa-kem is used in an AlgorithmIdentifier, the parameters 622 MUST employ the GenericHybridParameters syntax. The parameters MUST 623 be absent when used in the subjectPublicKeyInfo field The syntax for 624 GenericHybridParameters is as follows: 626 GenericHybridParameters ::= { 627 kem KeyEncapsulationMechanism, 628 dem DataEncapsulationMechanism 629 } 631 The fields of type GenericHybridParameters have the following 632 meanings: 634 o kem identifies the underlying key encapsulation mechanism. For the 635 RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from 636 ISO/IEC 18033-2. 638 The object identifier for RSA-KEM (as a key encapsulation 639 mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 as 641 id-kem-rsa OID ::= { 642 is18033-2 key-encapsulation-mechanism(2) rsa(4) 643 } 645 The associated parameters for id-kem-rsa have type 646 RsaKemParameters: 648 RsaKemParameters ::= { 649 keyDerivationFunction KeyDerivationFunction, 650 keyLength KeyLength 651 } 653 The fields of type RsaKemParameters have the following meanings: 655 * keyDerivationFunction identifies the underlying key 656 derivation function. For alignment with ANS X9.44, it 657 MUST be KDF2 or KDF3. However, other key derivation 658 functions MAY be used with CMS. Please see B.2.1 for 659 the syntax for KDF2 and KDF3. 661 KeyDerivationFunction ::= 662 AlgorithmIdentifier {{KDFAlgorithms}} 664 KDFAlgorithms ALGORITHM ::= { 665 kdf2 | kdf3, 666 ... -- implementations may define other methods 667 } 669 * keyLength is the length in bytes of the key-encrypting 670 key, which depends on the underlying symmetric key- 671 wrapping scheme. 673 KeyLength ::= INTEGER (1..MAX) 675 o dem identifies the underlying data encapsulation mechanism. For 676 alignment with ANS X9.44, it MUST be an X9-approved symmetric key- 677 wrapping scheme. (See Note.) However, other symmetric key-wrapping 678 schemes MAY be used with CMS. Please see B.2.2 for the syntax for 679 the AES, Triple-DES, and Camellia Key Wraps. 681 DataEncapsulationMechanism ::= 682 AlgorithmIdentifier {{DEMAlgorithms}} 684 DEMAlgorithms ALGORITHM ::= { 685 X9-SymmetricKeyWrappingSchemes, 686 Camellia-KeyWrappingSchemes, 687 ... -- implementations may define other methods 688 } 690 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 691 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 692 ... -- allows for future expansion 693 } 695 Camellia-KeyWrappingSchemes ALGORITHM ::= { 696 Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap 697 } 699 NOTE: The generic hybrid cipher in ISO/IEC 18033-2 can encrypt 700 arbitrary data, hence the term "data encapsulation mechanism". The 701 symmetric key-wrapping schemes take the role of data encapsulation 702 mechanisms in the RSA-KEM Key Transport Algorithm. ISO/IEC 18033-2 703 allows only three specific data encapsulation mechanisms, not 704 including any of these symmetric key-wrapping schemes. However, the 705 ASN.1 syntax in that document expects that additional algorithms will 706 be allowed. 708 B.2 710 B.2.1 Key Derivation Functions 712 The object identifier for KDF2 (see [ANS X9.44]) is: 714 id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } 716 The associated parameters identify the underlying hash function. For 717 alignment with ANS X9.44, the hash function MUST be an ASC X9- 718 approved hash function. However, other hash functions MAY be used 719 with CMS. 721 kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } 722 KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2- 723 HashFunctions}} 725 KDF2-HashFunctions ALGORITHM ::= { 726 X9-HashFunctions, 727 ... -- implementations may define other methods 728 } 730 X9-HashFunctions ALGORITHM ::= { 731 sha1 | sha224 | sha256 | sha384 | sha512, 732 ... -- allows for future expansion 733 } 735 The object identifier for SHA-1 is 737 id-sha1 OID ::= { 738 iso(1) identified-organization(3) oiw(14) secsig(3) 739 algorithms(2) sha1(26) 740 } 742 The object identifiers for SHA-224, SHA-256, SHA-384 and SHA-512 are 744 id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) } 745 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 746 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 747 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 749 There has been some confusion over whether the various SHA object 750 identifiers have a NULL parameter, or no associated parameters. As 751 also discussed in [PKCS1], implementations SHOULD generate algorithm 752 identifiers without parameters, and MUST accept algorithm identifiers 753 either without parameters, or with NULL parameters. 755 sha1 ALGORITHM ::= { OID id-sha1 } -- NULLParms MUST be 756 sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these 757 sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs 758 sha384 ALGORITHM ::= { OID id-sha384 } -- "" 759 sha512 ALGORITHM ::= { OID id-sha512 } -- "" 761 The object identifier for KDF3 (see [ANS X9.44]) is: 763 id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } 765 The associated parameters identify the underlying hash function. For 766 alignment with the draft ANS X9.44, the hash function MUST be an ASC 767 X9-approved hash function. (See Note.) However, other hash functions 768 MAY be used with CMS. 770 kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction } 772 KDF3-HashFunction ::= AlgorithmIdentifier { KDF3-HashFunctions } 774 KDF3-HashFunctions ALGORITHM ::= { 775 X9-HashFunctions, 776 ... -- implementations may define other methods 777 } 779 B.2.2 Symmetric Key-Wrapping Schemes 781 The object identifiers for the AES Key Wrap depends on the size of 782 the key encrypting key. There are three object identifiers (see 783 [AES-WRAP]): 785 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 786 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 787 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 789 These object identifiers have no associated parameters. 791 aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } 792 aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } 793 aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } 795 The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) 796 is 798 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 799 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 800 smime(16) alg(3) 6 801 } 803 This object identifier has a NULL parameter. 805 tdes-Wrap ALGORITHM ::= 806 { OID id-alg-CMS3DESwrap PARMS NullParms } 808 NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key 809 Wrap are in the process of being approved by ASC X9. 811 The object identifiers for the Camellia Key Wrap depend on the size 812 of the key encrypting key. There are three object identifiers: 814 id-camellia128-Wrap OBJECT IDENTIFIER ::= 815 { iso(1) member-body(2) 392 200011 61 security(1) 816 algorithm(1) key-wrap-algorithm(3) 817 camellia128-wrap(2) } 819 id-camellia192-Wrap OBJECT IDENTIFIER ::= 820 { iso(1) member-body(2) 392 200011 61 security(1) 821 algorithm(1) key-wrap-algorithm(3) 822 camellia192-wrap(3) } 824 id-camellia256-Wrap OBJECT IDENTIFIER ::= 825 { iso(1) member-body(2) 392 200011 61 security(1) 826 algorithm(1) key-wrap-algorithm(3) 827 camellia256-wrap(4) } 829 These object identifiers have no associated parameters. 831 camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } 832 camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } 833 camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } 835 B.3 ASN.1 module 837 CMS-RSA-KEM 838 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 839 pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } 841 DEFINITIONS ::= 843 BEGIN 845 -- EXPORTS ALL 847 -- IMPORTS None 849 -- Useful types and definitions 851 OID ::= OBJECT IDENTIFIER -- alias 853 -- Unless otherwise stated, if an object identifier has associated 855 -- parameters (i.e., the PARMS element is specified), the 856 -- parameters field shall be included in algorithm identifier 857 -- values. The parameters field shall be omitted if and only if 858 -- the object identifier does not have associated parameters 859 -- (i.e., the PARMS element is omitted), unless otherwise stated. 861 ALGORITHM ::= CLASS { 862 &id OBJECT IDENTIFIER UNIQUE, 863 &Type OPTIONAL 864 } 865 WITH SYNTAX { OID &id [PARMS &Type] } 867 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 868 algorithm ALGORITHM.&id( {IOSet} ), 869 parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL 870 } 872 NullParms ::= NULL 874 -- ISO/IEC 18033-2 arc 876 is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } 878 -- NIST algorithm arc 880 nistAlgorithm OID ::= { 881 joint-iso-itu-t(2) country(16) us(840) organization(1) 882 gov(101) csor(3) nistAlgorithm(4) 883 } 885 -- PKCS #1 arc 887 pkcs-1 OID ::= { 888 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 889 } 891 -- RSA-KEM Key Transport Algorithm 893 id-rsa-kem OID ::= { 894 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 895 pkcs-9(9) smime(16) alg(3) TBA 896 } 898 GenericHybridParameters ::= SEQUENCE { 899 kem KeyEncapsulationMechanism, 900 dem DataEncapsulationMechanism 901 } 903 KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}} 904 id-kem-rsa OID ::= { 905 is18033-2 key-encapsulation-mechanism(2) rsa(4) 906 } 908 RsaKemParameters ::= SEQUENCE { 909 keyDerivationFunction KeyDerivationFunction, 910 keyLength KeyLength 911 } 913 KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} 915 KDFAlgorithms ALGORITHM ::= { 916 kdf2 | kdf3, 917 ... -- implementations may define other methods 918 } 920 KeyLength ::= INTEGER (1..MAX) 922 DataEncapsulationMechanism ::= 923 AlgorithmIdentifier {{DEMAlgorithms}} 925 DEMAlgorithms ALGORITHM ::= { 926 X9-SymmetricKeyWrappingSchemes | 927 Camellia-KeyWrappingSchemes, 928 ... -- implementations may define other methods 929 } 931 X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { 932 aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, 933 ... -- allows for future expansion 934 } 936 X9-SymmetricKeyWrappingScheme ::= 937 AlgorithmIdentifier {{ X9-SymmetricKeyWrappingSchemes }} 939 Camellia-KeyWrappingSchemes ALGORITHM ::= { 940 camellia128-Wrap | camellia192-Wrap | camellia256-Wrap, 941 ... -- allows for future expansion 942 } 944 Camellia-KeyWrappingScheme ::= 945 AlgorithmIdentifier {{ Camellia-KeyWrappingSchemes }} 947 -- Key Derivation Functions 949 id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } 950 -- Base arc 952 x9-44 OID ::= { 953 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 954 x9Standards(9) x9-44(44) 955 } 957 x9-44-components OID ::= { x9-44 components(1) } 959 kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } 961 KDF2-HashFunction ::= AlgorithmIdentifier {{ KDF2-HashFunctions }} 963 KDF2-HashFunctions ALGORITHM ::= { 964 X9-HashFunctions, 965 ... -- implementations may define other methods 966 } 968 -- id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } kdf3 ALGORITHM 969 ::= { OID id-kdf-kdf2 PARMS KDF3-HashFunction } KDF3-HashFunction 970 ::= AlgorithmIdentifier {{ KDF3-HashFunctions }} 972 KDF3-HashFunctions ALGORITHM ::= { 973 X9-HashFunctions, 974 ... -- implementations may define other methods 975 } 977 -- Hash Functions 979 X9-HashFunctions ALGORITHM ::= { 980 sha1 | sha224 | sha256 | sha384 | sha512, 981 ... -- allows for future expansion 982 } 984 id-sha1 OID ::= { 985 iso(1) identified-organization(3) oiw(14) secsig(3) 986 algorithms(2) sha1(26) 987 } 989 id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha256(4) } 990 id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } 991 id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } 992 id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } 993 sha1 ALGORITHM ::= { OID id-sha1 } -- NullParms MUST be 994 sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these 995 sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs 996 sha384 ALGORITHM ::= { OID id-sha384 } -- "" 997 sha512 ALGORITHM ::= { OID id-sha512 } -- "" 999 -- Symmetric Key-Wrapping Schemes 1001 id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } 1002 id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } 1003 id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } 1005 aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } 1006 aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } 1007 aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } 1009 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { 1010 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1011 smime(16) alg(3) 6 1012 } 1014 tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms } 1016 id-camellia128-Wrap OBJECT IDENTIFIER ::= 1017 { iso(1) member-body(2) 392 200011 61 security(1) 1018 algorithm(1) key-wrap-algorithm(3) 1019 camellia128-wrap(2) } 1021 id-camellia192-Wrap OBJECT IDENTIFIER ::= 1022 { iso(1) member-body(2) 392 200011 61 security(1) 1023 algorithm(1) key-wrap-algorithm(3) 1024 camellia192-wrap(3) } 1026 id-camellia256-Wrap OBJECT IDENTIFIER ::= 1027 { iso(1) member-body(2) 392 200011 61 security(1) 1028 algorithm(1) key-wrap-algorithm(3) 1029 camellia256-wrap(4) } 1031 camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } 1032 camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } 1033 camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } 1035 END 1037 B.4 Examples 1039 As an example, if the key derivation function is KDF2 based onSHA-256 1040 and the symmetric key-wrapping scheme is the AES Key Wrap with a 128- 1041 bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport 1042 Algorithm will have the following value: 1044 SEQUENCE { 1045 id-rsa-kem, -- RSA-KEM cipher 1046 SEQUENCE { -- GenericHybridParameters 1047 SEQUENCE { -- key encapsulation mechanism 1048 id-kem-rsa, -- RSA-KEM 1049 SEQUENCE { -- RsaKemParameters 1050 SEQUENCE { -- key derivation function 1051 id-kdf-kdf2, -- KDF2 1052 SEQUENCE { -- KDF2-HashFunction 1053 id-sha256 -- SHA-256; no parameters (preferred) 1054 }, 1055 16 -- KEK length in bytes 1056 }, 1057 SEQUENCE { -- data encapsulation mechanism 1058 id-aes128-Wrap -- AES-128 Wrap; no parameters 1059 } 1060 } 1061 } 1063 This AlgorithmIdentifier value has the following DER encoding (?? 1064 indicates the algorithm number which is to be assigned): 1066 30 53 1067 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? -- id-rsa-kem 1068 30 44 1069 30 25 1070 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa 1071 30 1a 1072 30 16 1073 06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf2 1074 30 0b 1075 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 1076 02 10 -- 16 bytes 1077 30 0b 1078 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap 1080 The DER encodings for other typical sets of underlying components are 1081 as follows: 1083 o KDF2 based on SHA-384, AES Key Wrap with a 192-bit KEK 1085 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 1086 01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30 1087 1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09 1088 60 86 48 01 65 03 04 02 02 02 18 30 0b 06 09 60 1089 86 48 01 65 03 04 01 19 1091 o KDF2 based on SHA-512, AES Key Wrap with a 256-bit KEK 1093 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 1094 01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30 1095 1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09 1096 60 86 48 01 65 03 04 02 03 02 20 30 0b 06 09 60 1097 86 48 01 65 03 04 01 2d 1099 o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two- 1100 key triple-DES) 1102 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 1103 01 02 30 44 30 21 06 07 28 81 8c 71 02 02 04 30 1104 16 30 12 06 07 28 81 8c 71 02 05 02 30 07 06 05 1105 2b 0e 03 02 1a 02 10 30 0f 06 0b 2a 86 48 86 f7 1106 0d 01 09 10 03 06 05 00 1108 IANA Considerations 1110 Within the CMS, algorithms are identified by object identifiers 1111 (OIDs). With one exception, all of the OIDs used in this document 1112 were assigned in other IETF documents, in ISO/IEC standards 1113 documents, by the National Institute of Standards and Technology 1114 (NIST), and in Public-Key Cryptography Standards (PKCS) documents. 1115 The one exception is that the ASN.1 module's identifier (see Appendix 1116 B.3) is assigned in this document. No further action by the IANA is 1117 necessary for this document or any anticipated updates. 1119 Acknowledgments 1121 This document is one part of a strategy to align algorithm standards 1122 produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would 1123 like to thank the members of the ASC X9F1 working group for their 1124 contributions to drafts of ANS X9.44 which led to this specification. 1126 Our thanks to Russ Housley as well for his guidance and 1127 encouragement. We also appreciate the helpful direction we've 1128 received from Blake Ramsdell and Jim Schaad in bringing this document 1129 to fruition. A special thanks to Magnus Nystrom for his assistance on 1130 Appendix B. Thanks also to Bob Griffin and John Linn for both 1131 editorial direction and procedural guidance. 1133 Author Information 1135 James Randall 1137 Randall Consulting 1138 55 Sandpiper Drive 1139 Dover, NH 03820 1140 USA 1142 Email: jdrandall@comcast.net 1144 Burt Kaliski 1146 EMC 1147 176 South Street 1148 Hopkinton, MA 01748 1149 USA 1151 Email: kaliski_burt@emc.com 1153 John Brainard 1155 RSA, The Security Division of EMC 1156 174 Middlesex Turnpike 1157 Bedford, MA 01730 1158 USA 1159 Email: jbrainard@rsa.com 1161 Sean Turner 1163 IECA, Inc. 1164 3057 Nutley Street, Suite 106 1165 Fairfax, VA 22031 1166 USA 1168 Email: turners@ieca.com