idnits 2.17.1 draft-ietf-smime-password-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 646 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 94: '... [0] KeyDerivationAlgorithmIdentifier OPTIONAL,...' RFC 2119 keyword, line 138: '...CMS implementations MUST include PBKDF2 [RFC2898]. Appendix B...' RFC 2119 keyword, line 149: '... implementations MUST include Triple-D...' RFC 2119 keyword, line 150: '...in CBC mode, and MAY include other alg...' RFC 2119 keyword, line 152: '... implementations SHOULD NOT include an...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2001) is 8412 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) -- Missing reference section? 'RFC2640' on line 42 looks like a reference -- Missing reference section? 'ASN1' on line 44 looks like a reference -- Missing reference section? 'RFC2119' on line 49 looks like a reference -- Missing reference section? '1' on line 67 looks like a reference -- Missing reference section? '2' on line 68 looks like a reference -- Missing reference section? '3' on line 491 looks like a reference -- Missing reference section? '0' on line 603 looks like a reference -- Missing reference section? 'RFC 2898' on line 121 looks like a reference -- Missing reference section? 'RFC2898' on line 138 looks like a reference -- Missing reference section? 'PACKAGE' on line 175 looks like a reference -- Missing reference section? 'RFC2268' on line 295 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Peter Gutmann 2 draft-ietf-smime-password-03.txt University of Auckland 3 October 21, 2000 4 Expires April 2001 6 Password-based Encryption for S/MIME 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The Cryptographic Message Syntax data format doesn't currently 31 contain any provisions for password-based data encryption. This 32 document provides a method of encrypting data using user-supplied 33 passwords and, by extension, any form of variable-length keying 34 material which isn't necessarily an algorithm-specific fixed-format 35 key. 37 1. Introduction 39 This document describes a password-based content encryption mechanism 40 for S/MIME. This is implemented as a new RecipientInfo type and is 41 an extension to the RecipientInfo types currently defined in RFC 2640 42 [RFC2640]. 44 The format of the messages are described in ASN.1 [ASN1]. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 47 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 48 interpreted as described in [RFC2119]. 50 1.1 Password-based Content Encryption 52 CMS currently defined three recipient information types for public- 53 key key wrapping (KeyTransRecipientInfo), conventional key wrapping 54 (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The 55 recipient information described here adds a fourth type, 56 PasswordRecipientInfo, which provides for password-based key 57 wrapping. 59 1.2 RecipientInfo Types 61 The new recipient information type is an extension to the 62 RecipientInfo type defined in section 6.2 of CMS, extending the types 63 to: 65 RecipientInfo ::= CHOICE { 66 ktri KeyTransRecipientInfo, 67 kari [1] KeyAgreeRecipientInfo, 68 kekri [2] KEKRecipientInfo, 69 pwri [3] PasswordRecipientinfo -- New RecipientInfo type 70 } 72 Although the recipient information generation process is described in 73 terms of a password-based operation (since this will be its most 74 common use), the transformation employed is a general-purpose key 75 derivation one which allows any type of keying material to be 76 converted into a key specific to a particular content-encryption 77 algorithm. Since the most common use for password-based encryption 78 is to encrypt files which are stored locally (rather than being 79 transmitted across a network), the term "recipient" is somewhat 80 misleading, but is used here because the other key transport 81 mechanisms have always been described in similar terms. 83 1.2.1 PasswordRecipientInfo Type 85 Recipient information using a user-supplied password or previously 86 agreed-upon key is represented in the type PasswordRecipientInfo. 87 Each instance of PasswordRecipientInfo will transfer the content- 88 encryption key (CEK) to one or more recipients who have the 89 previously agreed-upon password or key-encryption key (KEK). 91 PasswordRecipientInfo ::= SEQUENCE { 92 version CMSVersion, -- Always set to 0 93 keyDerivationAlgorithm 94 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 95 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 96 encryptedKey EncryptedKey } 98 The fields of type PasswordRecipientInfo have the following meanings: 100 version is the syntax version number. It shall always be 0. 102 keyDerivationAlgorithm identifies the key-derivation algorithm, and 103 any associated parameters, used to derive the KEK from the user- 104 supplied password. If this field is absent, the KEK is supplied 105 from an external source, for example a crypto token such as a smart 106 card. 108 keyEncryptionAlgorithm identifies the content-encryption algorithm, 109 and any associated parameters, used to encrypt the CEK with the 110 KEK. 112 encryptedKey is the result of encrypting the content-encryption key 113 with the KEK. 115 1.2.2 Rationale 117 Password-based key wrapping is a two-stage process, a first stage in 118 which a user-supplied password is converted into a KEK if required, 119 and a second stage in which the KEK is used to encrypt a CEK. These 120 two stages are identified by the two algorithm identifiers. Although 121 the PKCS #5v2 standard [RFC 2898] goes one step further to wrap these 122 up into a single algorithm identifier, this design is particular to 123 that standard and may not be applicable for other key wrapping 124 mechanisms. For this reason the two steps are specified separately. 126 2 Supported Algorithms 128 This section lists the algorithms that must be implemented. 129 Additional algorithms that should be implemented are also included. 131 2.1 Key Derivation Algorithms 133 These algorithms are used to convert the password into a KEK. The 134 key derivation algorithms are: 136 KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier 138 CMS implementations MUST include PBKDF2 [RFC2898]. Appendix B 139 contains a more precise definition of the allowed algorithm type than 140 is possible using 1988 ASN.1. 142 2.2 Key Encryption Algorithms 144 These algorithms are used to encrypt the content (the key) using the 145 derived KEK. The content encryption algorithms are PBES2-Encs [RFC 146 2898]. Appendix B contains a more precise definition of the allowed 147 algorithm types than is possible using 1988 ASN.1. 149 CMS implementations MUST include Triple-DES in CBC mode, SHOULD 150 include RC2 in CBC mode, and MAY include other algorithms such as 151 AES, CAST-128, RC5, IDEA, Skipjack, Blowfish, and encryption modes as 152 required. CMS implementations SHOULD NOT include any KSG ciphers 153 such as RC4 or a block cipher in OFB mode, and SHOULD NOT include a 154 block cipher in ECB mode. The use of RC2 has special requirements, 155 see section 2.4 for details. 157 2.3 Symmetric Key Encryption Algorithms 159 The key wrap algorithm is used to wrap the CEK with the KEK. There 160 is no requirement that the content-encryption algorithm match the KEK 161 algorithm, although care should be taken to ensure that, if different 162 algorithms are used, they offer an equivalent level of security (for 163 example wrapping a Triple-DES key with an RC2/40 key leads to a 164 severe impedance mismatch in encryption strength). 166 The key wrap algorithm specified below is independent of the content- 167 encryption or wrapping algorithms, relying only on the use of a block 168 cipher to perform the wrapping. 170 2.3.1 Key Wrap 172 The key wrap algorithm encrypts a CEK with a KEK in a manner which 173 ensures that every bit of plaintext effects every bit of ciphertext. 174 This makes it equivalent in function to the package transform 175 [PACKAGE] without requiring additional mechanisms or resources such 176 as hash functions or cryptographically strong random numbers. The 177 key wrap algorithm is performed in two phases, a first phase which 178 formats the CEK into a form suitable for encryption by the KEK, and a 179 second phase which wraps the formatted CEK using the KEK. 181 Key formatting: Create a formatted CEK block consisting of the 182 following: 184 1. A one-byte count of the number of bytes in the CEK. 186 2. A check value containing the bitwise complement of the first 187 three bytes of the CEK. 189 3. The CEK. 191 4. Enough random padding data to make the CEK data block at least 192 two KEK cipher blocks long (the fact that 32 bits of count+check 193 value are used means that even with a 40-bit CEK, the resulting 194 data size will always be at least two (64-bit) cipher blocks 195 long). The padding data does not have to be cryptographically 196 strong, although unpredictability helps. 198 The formatted CEK block then looks as follows: 200 CEK byte count || check value || CEK || padding (if required) 202 Key wrapping: 204 1. Encrypt the padded key using the KEK. 206 2. Without resetting the IV (that is, using the last ciphertext 207 block as the IV), encrypt the encrypted padded key a second 208 time. 210 The resulting double-encrypted data is the EncryptedKey. 212 2.3.2 Key Unwrap 214 Key unwrapping: 216 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th 217 ciphertext block. 219 2. Using the decrypted n'th ciphertext block as the IV, decrypt the 220 1st ... n-1'th ciphertext blocks. This strips the outer layer 221 of encryption. 223 3. Decrypt the inner layer of encryption using the KEK. 225 Key format verification: 227 1a.If the CEK byte count is less than the minimum allowed key size 228 (usually 5 bytes for 40-bit keys) or greater than the wrapped 229 CEK length or not valid for the CEK algorithm (eg not 16 or 24 230 bytes for triple DES), the KEK was invalid. 231 1b.If the bitwise complement of the key check value doesn't match 232 the first three bytes of the key, the KEK was invalid. 234 2.3.3 Example 236 Given a content-encryption algorithm of Skipjack and a KEK algorithm 237 of Triple-DES, the wrap steps are as follows: 239 1. Set the first 4 bytes of the CEK block to the Skipjack key size 240 (10 bytes) and the bitwise complement of the first three bytes 241 of the CEK. 243 2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16 244 bytes (two triple-DES blocks) using 2 bytes of random data. 246 2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, 247 encrypted the padded Skipjack key. 249 3. Without resetting the IV, encrypt the encrypted padded key a 250 second time. 252 The unwrap steps are as follows: 254 1. Using the first 8 bytes of the double-encrypted key as the IV, 255 decrypt the second 8 bytes. 257 2. Without resetting the IV, decrypt the first 8 bytes. 259 3. Decrypt the inner layer of encryption using the the IV given in 260 the KeyEncryptionAlgorithmIdentifer to recover the padded 261 Skipjack key. 263 4. If the length byte isn't equal to the Skipjack key size (80 bits 264 or 10 bytes) or the bitwise complement of the check bytes 265 doesn't match the first three bytes of the CEK, the KEK was 266 invalid. 268 2.3.4 Rationale for the Double Wrapping 270 If many CEK's are encrypted in a standard way with the same KEK and 271 the KEK has a 64-bit block size then after about 2^32 encryptions 272 there is a high probability of a collision between different blocks 273 of encrypted CEK's. If an opponent manages to obtain a CEK, they may 274 be able to solve for other CEK's. The double-encryption wrapping 275 process, which makes every bit of ciphertext dependent on every bit 276 of the CEK, eliminates this collision problem (as well as preventing 277 other potential problems such as bit-flipping attacks). Since the IV 278 is applied to the inner layer of encryption, even wrapping the same 279 CEK with the same KEK will result in a completely different wrapped 280 key each time. 282 An additional feature of the double wrapping is that it doens't 283 require the use of any extra algorithms such as hash algorithms in 284 addition to the wrapping algorithm itself, allowing it to be 285 implemented in devices which only support one type of encryption 286 algorithm. A typical example of such a device is a crypto token such 287 as a smart card which often only supports a single block cipher and a 288 single public-key algorithm, making it impossible to wrap keys if the 289 use of an additional algorithm were required. 291 2.4 Special Handling for RC2 Keys 293 For a variety of historical, political, and software-peculiarity 294 reasons which are beyond the scope of this document, the handling of 295 keys for the RC2 algorithm [RFC2268] by different implementations is 296 somewhat arbitrary. In particular, the choice of actual vs effective 297 key bits used in the algorithm is often unclear. The standard RC2 298 AlgorithmIdentifier only allows the effective key bits to be 299 specified, leaving the actual key bits to be communicated via out-of- 300 band means, which in some cases means hardcoding them into 301 applications. Solving this problem requires two things, a precise 302 definition of how keys represented with the standard RC2 303 AlgorithmIdentifier are handled, and a new RC2 AlgorithmIdentifier 304 which allows keys currently in use by different applications to be 305 handled. 307 2.4.1 Handling of RC2 with RFC 2268 AlgorithmIdentifier 309 RFC 2268 defines the following AlgorithmIdentifier for RC2: 311 rc2CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840) 312 rsadsi(113549) encryptionAlgorithm(3) 2} 314 RC2-CBCParameter ::= CHOICE { 315 iv IV, 316 params SEQUENCE { 317 version INTEGER, 318 iv OCTET STRING 319 } 320 } 322 where the version field encodes the effective key size in a complex 323 manner specified in the RFC. Where this algorithm identifier is 324 used, the actual key size shall be the same size as the effective key 325 size as given by the version field. When RC2 is to be used, 326 implementations should use this AlgorithmIdentifier and parameters, 327 and when this AlgorithmIdentifier is used the actual key size MUST 328 NOT be a value other than the effective key size (to use a different 329 size, see section 2.4.2). 331 2.4.2 Handling of RC2 with Other Key Sizes 333 If the use of an actual key size of other than the effective key size 334 is required, implementations MUST use the following 335 AlgorithmIdentifier: 337 id-alg-pwri-rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13} 338 pwri-rc2CBCParameter ::= SEQUENCE { 339 actualKeySize INTEGER, -- Actual key size in bits 340 effectiveKeySize INTEGER, -- Effective key size in bits 341 iv OCTET STRING 342 } 344 This allows arbitrary actual and effective key sizes to be specified 345 for compatibility with existing usage. Although implementations 346 SHOULD NOT use this alternative (using instead the one in section 347 2.4.1) experience has shown that implementors will continue to use 348 oddball RC2 parameters anyway, so new implementations should be 349 prepared to encounter and handle actual and effective key sizes 350 ranging from 40 up to around 200 bits. 352 2.4.3 Rationale 354 The reason for providing for the handling of oddball key sizes is 355 compatibility with existing applications, for example a mailing-list 356 exploder or mail gateway may take an RSA-wrapped CEK generated by a 357 current application and repackage it with a KEK, so we need a 358 mechanism for handling strange key lengths in a manner which is 359 compatible with existing usage. The alternative RC2 360 AlgorithmIdentifier, although not recommended, provides a means of 361 ensuring this compatibility. 363 3. Test Vectors 365 This section contains two sets of test vectors, a very basic set for 366 DES which can be used to verify correctness and which uses an 367 algorithm which is freely exportable from the US, and a stress-test 368 version which uses very long passphrase and key sizes and a mixture 369 of algorithms which can be used to verify the behaviour in extreme 370 cases. 372 The basic test contains two subtests, a known-answer test for the key 373 derivation stage and a full test of the key wrapping. Both tests use 374 a DES-CBC key derived from the password "password" with salt { 12 34 375 56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known 376 answer test the IV is set to all zeroes (equivalent to using ECB) and 377 used to encrypt an all-zero data block. 379 The following values are obtained for the known-answer test: 381 PKCS #5v2 values: 383 input 70 61 73 73 77 6f 72 64 384 passphrase: "password" 385 input salt: 12 34 56 78 78 56 34 12 386 iterations: 5 388 output key: D1 DA A7 86 15 F2 87 E6 389 known answer: 9B BD 78 FC 11 A3 A9 08 391 The following values are obtained when wrapping a 64-bit (parity- 392 adjusted) DES-EBC key: 394 PKCS #5v2 values: 396 input 70 61 73 73 77 6f 72 64 397 passphrase: "password" 398 input salt: 12 34 56 78 78 56 34 12 399 iterations: 5 401 output key: D1 DA A7 86 15 F2 87 E6 403 CEK formatting phase: 405 length byte: 08 406 key check: 73 9D 83 407 CEK: 8C 62 7C 89 73 23 A2 F8 408 padding: C4 36 F5 41 410 complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 411 CEK block: 413 Key wrap phase (wrap CEK block using 3DES key): 415 IV: EF E5 98 EF 21 B3 3D 6D 417 first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4 418 pass output: 419 second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 420 pass output: 422 ASN.1 encoded PasswordRecipientInfo: 424 0 A3 68: [3] { 425 2 02 1: INTEGER 0 426 5 A0 26: [0] { 427 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 428 18 30 13: SEQUENCE { 429 20 04 8: OCTET STRING 430 : 12 34 56 78 78 56 34 12 431 30 02 1: INTEGER 5 432 : } 433 : } 434 33 30 17: SEQUENCE { 435 35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7) 436 42 04 8: OCTET STRING 437 : EF E5 98 EF 21 B3 3D 6D 438 : } 439 52 04 16: OCTET STRING 440 : B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 441 : } 443 The following values are obtained when wrapping a 256-bit key (for 444 example one for AES or Blowfish) using a triple DES-CBC key derived 445 from the passphrase "All n-entities must communicate with other n- 446 entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12} 447 using 500 iterations of PBKDF2. 449 PKCS #5v2 values: 451 input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D 452 passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 453 77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74 454 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 455 74 69 74 65 65 68 65 65 68 65 65 73 456 "All n-entities must communicate with other " 457 "n-entities via n-1 entiteeheehees" 458 input 459 salt: 12 34 56 78 78 56 34 12 460 iterations: 500 462 output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 463 3DES key: 07 12 63 80 CC 47 AB 2D 465 CEK formatting phase: 467 length byte: 20 468 key check: 73 9C 82 469 CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 470 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B 471 padding: FA 06 0A 45 473 complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 474 CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 475 C7 1B AF 3B FA 06 0A 45 477 Key wrap phase (wrap CEK block using 3DES key): 479 IV: BA F1 CA 79 31 21 3C 4E 481 first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD 482 pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 483 96 9E 65 27 9E 12 6A EB 485 second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 486 pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 487 EC 74 E6 CA D7 DB 26 0C 489 ASN.1 encoded PasswordRecipientInfo: 491 0 A3 96: [3] { 492 2 02 1: INTEGER 0 493 5 A0 27: [0] { 494 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 495 18 30 14: SEQUENCE { 496 20 04 8: OCTET STRING 497 : 12 34 56 78 78 56 34 12 498 30 02 2: INTEGER 500 499 : } 500 : } 501 34 30 20: SEQUENCE { 502 36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) 503 46 04 8: OCTET STRING 504 : BA F1 CA 79 31 21 3C 4E 505 : } 506 56 04 40: OCTET STRING 507 : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 508 : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 509 : EC 74 E6 CA D7 DB 26 0C 510 : } 512 4. Security Considerations 514 The security of this recipient information type rests on the security 515 of the underlying mechanisms employed, for which further information 516 can be found in RFC 2640 and PKCS5v2. More importantly, however, 517 when used with a password the security of this information type rests 518 on the entropy of the user-selected password, which is typically 519 quite low. Pass phrases (as opposed to simple passwords) are STRONGLY 520 RECOMMENDED, although it should be recognized that even with pass 521 phrases it will be difficult to use this recipient information type 522 to derive a KEK with sufficient entropy to properly protect a 128-bit 523 (or higher) CEK. 525 Author Address 527 Peter Gutmann 528 University of Auckland 529 Private Bag 92019 530 Auckland, New Zealand 531 pgut001@cs.auckland.ac.nz 533 References 535 ASN1 Recommendation X.680: Specification of Abstract Syntax 536 Notation One (ASN.1), 1994. 538 RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels, 539 S.Bradner, March 1997. 541 RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest, 542 March 1998. 544 RFC2630 Cryptographic Message Syntax, R.Housley, June 1999. 546 RFC2898 PKCS #5: Password-Based Cryptography Specification, Version 547 2.0, B.Kaliski, September 2000. 549 PACKAGE All-or-Nothing Encryption and the Package Transform, 550 R.Rivest, Proceedings of Fast Software Encryption '97, Haifa, 551 Israel, January 1997. 553 Appendix A: ASN.1:1988 Module 555 PasswordRecipientInfo 556 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 557 smime(16) modules(0) pwri(12) } 559 DEFINITIONS IMPLICIT TAGS ::= 560 BEGIN 562 IMPORTS 564 FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 565 pkcs-5(5) } 566 PBKDF2-params, PBES2-Encs; 568 PasswordRecipientInfo ::= SEQUENCE { 569 version CMSVersion, -- Always set to 0 570 keyDerivationAlgorithm 571 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 572 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 573 encryptedKey EncryptedKey } 575 KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier 577 KeyEncryptionAlgorithmIdentifer ::= AlgorithmIdentifier 579 END 581 Appendix B: ASN.1:1994 Module 583 This appendix contains the same information as Appendix A in a more 584 recent (and precise) ASN.1 notation, however Appendix A takes 585 precedence in case of conflict. 587 PasswordRecipientInfo 588 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 589 smime(16) modules(0) pwri(12) } 591 DEFINITIONS IMPLICIT TAGS ::= 592 BEGIN 594 IMPORTS 596 FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 597 pkcs-5(5) } 598 PBKDF2-params, PBES2-Encs; 600 PasswordRecipientInfo ::= SEQUENCE { 601 version CMSVersion, -- Always set to 0 602 keyDerivationAlgorithm 603 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 604 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 605 encryptedKey EncryptedKey } 607 KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { 608 { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, 609 ... 610 } 612 KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs 614 END 616 Full Copyright Statement 618 Copyright (C) The Internet Society 2000. All Rights Reserved. 620 This document and translations of it may be copied and furnished to 621 others, and derivative works that comment on or otherwise explain it 622 or assist in its implementation may be prepared, copied, published 623 and distributed, in whole or in part, without restriction of any 624 kind, provided that the above copyright notice and this paragraph are 625 included on all such copies and derivative works. However, this 626 document itself may not be modified in any way, such as by removing 627 the copyright notice or references to the Internet Society or other 628 Internet organizations, except as needed for the purpose of 629 developing Internet standards in which case the procedures for 630 copyrights defined in the Internet Standards process must be 631 followed, or as required to translate it into languages other than 632 English. 634 The limited permissions granted above are perpetual and will not be 635 revoked by the Internet Society or its successors or assigns. 637 This document and the information contained herein is provided on an 638 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 639 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 640 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 641 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 642 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.