idnits 2.17.1 draft-ietf-smime-password-04.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 703 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 7 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 92: '... [0] KeyDerivationAlgorithmIdentifier OPTIONAL,...' RFC 2119 keyword, line 98: '...sion number. It MUST be 0. Details o...' RFC 2119 keyword, line 129: '...NCE OF everything-imaginable OPTIONAL,...' RFC 2119 keyword, line 151: '...Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B...' RFC 2119 keyword, line 177: '... implementations MUST implement the id...' (10 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 (January 2002) is 8130 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 43 looks like a reference -- Missing reference section? 'ASN1' on line 45 looks like a reference -- Missing reference section? 'RFC2119' on line 50 looks like a reference -- Missing reference section? '1' on line 66 looks like a reference -- Missing reference section? '2' on line 67 looks like a reference -- Missing reference section? '3' on line 449 looks like a reference -- Missing reference section? '0' on line 629 looks like a reference -- Missing reference section? 'RFC2630' on line 99 looks like a reference -- Missing reference section? 'RFC2898' on line 151 looks like a reference -- Missing reference section? 'PACKAGE' on line 203 looks like a reference -- Missing reference section? 'RFC 2898' on line 567 looks like a reference Summary: 5 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-04.txt University of Auckland 3 July 17, 2001 4 Expires January 2002 6 Password-based Encryption for CMS 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 Copyright (C) The Internet Society July 2001. All Rights Reserved. 30 Abstract 32 The Cryptographic Message Syntax data format doesn't currently contain 33 any provisions for password-based data encryption. This document 34 provides a method of encrypting data using user-supplied passwords and, 35 by extension, any form of variable-length keying material which isn't 36 necessarily an algorithm-specific fixed-format key. 38 1. Introduction 40 This document describes a password-based content encryption mechanism 41 for S/MIME. This is implemented as a new RecipientInfo type and is an 42 extension to the RecipientInfo types currently defined in RFC 2640 43 [RFC2640]. 45 The format of the messages are described in ASN.1 [ASN1]. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 48 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 49 interpreted as described in [RFC2119]. 51 1.1 Password-based Content Encryption 53 CMS currently defined three recipient information types for public- key 54 key wrapping (KeyTransRecipientInfo), conventional key wrapping 55 (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The 56 recipient information described here adds a fourth type, 57 PasswordRecipientInfo, which provides for password- based key wrapping. 59 1.2 RecipientInfo Types 61 The new recipient information type is an extension to the RecipientInfo 62 type defined in section 6.2 of CMS, extending the types to: 64 RecipientInfo ::= CHOICE { 65 ktri KeyTransRecipientInfo, 66 kari [1] KeyAgreeRecipientInfo, 67 kekri [2] KEKRecipientInfo, 68 pwri [3] PasswordRecipientinfo -- New RecipientInfo type 69 } 71 Although the recipient information generation process is described in terms of 72 a password-based operation (since this will be its most common use), the 73 transformation employed is a general-purpose key derivation one which allows 74 any type of keying material to be converted into a key specific to a particular 75 content-encryption algorithm. Since the most common use for password-based 76 encryption is to encrypt files which are stored locally (rather than being 77 transmitted across a network), the term "recipient" is somewhat misleading, but 78 is used here because the other key transport mechanisms have always been 79 described in similar terms. 81 1.2.1 PasswordRecipientInfo Type 83 Recipient information using a user-supplied password or previously 84 agreed-upon key is represented in the type PasswordRecipientInfo. Each 85 instance of PasswordRecipientInfo will transfer the content-encryption 86 key (CEK) to one or more recipients who have the previously agreed-upon 87 password or key-encryption key (KEK). 89 PasswordRecipientInfo ::= SEQUENCE { 90 version CMSVersion, -- Always set to 0 91 keyDerivationAlgorithm 92 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 93 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 94 encryptedKey EncryptedKey } 96 The fields of type PasswordRecipientInfo have the following meanings: 98 version is the syntax version number. It MUST be 0. Details of the 99 CMSVersion type are discussed in CMS [RFC2630], section 10.2.5. 101 keyDerivationAlgorithm identifies the key-derivation algorithm, and 102 any associated parameters, used to derive the KEK from the user- 103 supplied password. If this field is absent, the KEK is supplied from 104 an external source, for example a crypto token such as a smart card. 106 keyEncryptionAlgorithm identifies the key-encryption algorithm, and 107 any associated parameters, used to encrypt the CEK with the KEK. 109 encryptedKey is the result of encrypting the content-encryption key 110 with the KEK. 112 1.2.2 Rationale 114 Password-based key wrapping is a two-stage process, a first stage in 115 which a user-supplied password is converted into a KEK if required, and 116 a second stage in which the KEK is used to encrypt a CEK. These two 117 stages are identified by the two algorithm identifiers. Although the 118 PKCS #5v2 standard [RFC2898] goes one step further to wrap these up 119 into a single algorithm identifier, this design is particular to that 120 standard and may not be applicable for other key wrapping mechanisms. 121 For this reason the two steps are specified separately. 123 The current format doesn't provide any means of differentiating between 124 multiple password recipient info's, which would occur for example if 125 two passwords are used to encrypt the same data. Unfortunately there 126 is a lack of existing practice in this area, since typical applications 127 follow the model of encrypting data such as a file with a single 128 password obtained from the user. Two possible options would be to use 129 an OCTET STRING hole or a SEQUENCE OF everything-imaginable OPTIONAL, 130 however without any clear indication of what's required it's probable 131 that every implementation will choose to interpret the field 132 differently, leading to non-interoperability between applications. 133 Given this incompleteness, an appropriate mechanism would be difficult 134 (perhaps impossible) to define at this time. If sufficient demand 135 emerges then this may be addressed in a future version of this 136 document, for example by adding an optional identification field of an 137 appropriate form. 139 2 Supported Algorithms 141 This section lists the algorithms that must be implemented. Additional 142 algorithms that should be implemented are also included. 144 2.1 Key Derivation Algorithms 146 These algorithms are used to convert the password into a KEK. The key 147 derivation algorithms are: 149 KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier 151 Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B 152 contains a more precise definition of the allowed algorithm type than 153 is possible using 1988 ASN.1. 155 2.2 Key Encryption Algorithms 157 These algorithms are used to encrypt the CEK using the derived KEK. 158 The key encryption algorithms are: 160 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 162 The PasswordRecipientInfo key encryption algorithm identifier is: 164 id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2) 165 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 } 167 The AlgorithmIdentifier parameters field for this algorithm contains 168 the KEK encryption algorithm used with the the key wrap algorithm 169 specified in section 2.3. 171 There is no requirement that the CEK algorithm match the KEK encryption 172 algorithm, although care should be taken to ensure that, if different 173 algorithms are used, they offer an equivalent level of security (for 174 example wrapping a Triple-DES key with an RC2/40 key leads to a severe 175 impedance mismatch in encryption strength). 177 Conforming implementations MUST implement the id-alg-PWRI-KEK key wrap 178 algorithm. For the KEK encryption algorithms used by id-alg-PWRI-KEK, 179 conforming implementations MUST include Triple-DES in CBC mode and MAY 180 include other algorithms such as AES, CAST-128, RC5, IDEA, Skipjack, 181 Blowfish, and encryption modes as required. Implementations SHOULD NOT 182 include any KSG (keystream generator) ciphers such as RC4 or a block 183 cipher in OFB mode, and SHOULD NOT include a block cipher in ECB mode. 185 2.2.1 Rationale 187 The use of a level of indirection in specifying the 188 KeyEncryptionAlgorithmIdentifier allows alternative wrapping algorithms 189 to be used in the future. If the KEK algorithm were specified directly 190 in this field then any use of an alternative wrapping algorithm would 191 require a change to the PasswordRecipientInfo structure rather than 192 simply a change to the key encryption algorithm identifier. 194 The parameter field for this algorithm identifier could be specified to 195 default to triple-DES, however due to the confusion over NULL vs absent 196 parameters in algorithm identifiers it's left explicit with no default 197 value. 199 2.3.1 Key Wrap 201 The key wrap algorithm encrypts a CEK with a KEK in a manner which 202 ensures that every bit of plaintext effects every bit of ciphertext. 203 This makes it equivalent in function to the package transform [PACKAGE] 204 without requiring additional mechanisms or resources such as hash 205 functions or cryptographically strong random numbers. The key wrap 206 algorithm is performed in two phases, a first phase which formats the 207 CEK into a form suitable for encryption by the KEK, and a second phase 208 which wraps the formatted CEK using the KEK. 210 Key formatting: Create a formatted CEK block consisting of the 211 following: 213 1. A one-byte count of the number of bytes in the CEK. 215 2. A check value containing the bitwise complement of the first three 216 bytes of the CEK. 218 3. The CEK. 220 4. Enough random padding data to make the CEK data block a multiple 221 of the KEK block length and at least two KEK cipher blocks long 222 (the fact that 32 bits of count+check value are used means that 223 even with a 40-bit CEK, the resulting data size will always be at 224 least two (64-bit) cipher blocks long). The padding data does not 225 have to be cryptographically strong, although unpredictability 226 helps. 228 The formatted CEK block then looks as follows: 230 CEK byte count || check value || CEK || padding (if required) 232 Key wrapping: 234 1. Encrypt the padded key using the KEK. 236 2. Without resetting the IV (that is, using the last ciphertext block 237 as the IV), encrypt the encrypted padded key a second time. 239 The resulting double-encrypted data is the EncryptedKey. 241 2.3.2 Key Unwrap 243 Key unwrapping: 245 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th 246 ciphertext block. 248 2. Using the decrypted n'th ciphertext block as the IV, decrypt the 249 1st ... n-1'th ciphertext blocks. This strips the outer layer of 250 encryption. 252 3. Decrypt the inner layer of encryption using the KEK. 254 Key format verification: 256 1a.If the CEK byte count is less than the minimum allowed key size 257 (usually 5 bytes for 40-bit keys) or greater than the wrapped CEK 258 length or not valid for the CEK algorithm (eg not 16 or 24 bytes 259 for triple DES), the KEK was invalid. 261 1b.If the bitwise complement of the key check value doesn't match the 262 first three bytes of the key, the KEK was invalid. 264 2.3.3 Example 266 Given a content-encryption algorithm of Skipjack and a KEK algorithm of 267 Triple- DES, the wrap steps are as follows: 269 1. Set the first 4 bytes of the CEK block to the Skipjack key size 270 (10 bytes) and the bitwise complement of the first three bytes of 271 the CEK. 273 2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16 274 bytes (two triple-DES blocks) using 2 bytes of random data. 276 2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, 277 encrypted the padded Skipjack key. 279 3. Without resetting the IV, encrypt the encrypted padded key a second time. 281 The unwrap steps are as follows: 283 1. Using the first 8 bytes of the double-encrypted key as the IV, 284 decrypt the second 8 bytes. 286 2. Without resetting the IV, decrypt the first 8 bytes. 288 3. Decrypt the inner layer of encryption using the the IV given in 289 the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack 290 key. 292 4. If the length byte isn't equal to the Skipjack key size (80 bits 293 or 10 bytes) or the bitwise complement of the check bytes doesn't 294 match the first three bytes of the CEK, the KEK was invalid. 296 2.3.4 Rationale for the Double Wrapping 298 If many CEK's are encrypted in a standard way with the same KEK and the 299 KEK has a 64-bit block size then after about 2^32 encryptions there is 300 a high probability of a collision between different blocks of encrypted 301 CEK's. If an opponent manages to obtain a CEK, they may be able to 302 solve for other CEK's. The double-encryption wrapping process, which 303 makes every bit of ciphertext dependent on every bit of the CEK, 304 eliminates this collision problem (as well as preventing other 305 potential problems such as bit-flipping attacks). Since the IV is 306 applied to the inner layer of encryption, even wrapping the same CEK 307 with the same KEK will result in a completely different wrapped key 308 each time. 310 An additional feature of the double wrapping is that it doens't require 311 the use of any extra algorithms such as hash algorithms in addition to 312 the wrapping algorithm itself, allowing it to be implemented in devices 313 which only support one type of encryption algorithm. A typical example 314 of such a device is a crypto token such as a smart card which often 315 only supports a single block cipher and a single public-key algorithm, 316 making it impossible to wrap keys if the use of an additional algorithm 317 were required. 319 3. Test Vectors 321 This section contains two sets of test vectors, a very basic set for 322 DES which can be used to verify correctness and which uses an algorithm 323 which is freely exportable from the US, and a stress-test version which 324 uses very long passphrase and key sizes and a mixture of algorithms 325 which can be used to verify the behaviour in extreme cases. 327 The basic test contains two subtests, a known-answer test for the key 328 derivation stage and a full test of the key wrapping. Both tests use a 329 DES-CBC key derived from the password "password" with salt { 12 34 56 330 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known answer 331 test the IV is set to all zeroes (equivalent to using ECB) and used to 332 encrypt an all-zero data block. 334 The following values are obtained for the known-answer test: 336 PKCS #5v2 values: 338 input 70 61 73 73 77 6f 72 64 339 passphrase: "password" 340 input salt: 12 34 56 78 78 56 34 12 341 iterations: 5 343 output key: D1 DA A7 86 15 F2 87 E6 344 known answer: 9B BD 78 FC 11 A3 A9 08 346 The following values are obtained when wrapping a 64-bit (parity- 347 adjusted) DES-EBC key: 349 PKCS #5v2 values: 351 input 70 61 73 73 77 6f 72 64 352 passphrase: "password" 353 input salt: 12 34 56 78 78 56 34 12 354 iterations: 5 356 output key: D1 DA A7 86 15 F2 87 E6 358 CEK formatting phase: 360 length byte: 08 361 key check: 73 9D 83 362 CEK: 8C 62 7C 89 73 23 A2 F8 363 padding: C4 36 F5 41 365 complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 366 CEK block: 368 Key wrap phase (wrap CEK block using 3DES key): 370 IV: EF E5 98 EF 21 B3 3D 6D 372 first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4 373 pass output: 374 second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 375 pass output: 377 ASN.1 encoded PasswordRecipientInfo: 379 0 A3 68: [3] { 380 2 02 1: INTEGER 0 381 5 A0 26: [0] { 382 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 383 18 30 13: SEQUENCE { 384 20 04 8: OCTET STRING 385 : 12 34 56 78 78 56 34 12 386 30 02 1: INTEGER 5 387 : } 388 : } 389 34 30 32: SEQUENCE { 390 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK (1 2 840 113549 1 9 16 3 9) 391 33 30 17: SEQUENCE { 392 35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7) 393 42 04 8: OCTET STRING 394 : EF E5 98 EF 21 B3 3D 6D 395 : } 396 : } 397 68 04 16: OCTET STRING 398 : B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 399 : } 401 The following values are obtained when wrapping a 256-bit key (for 402 example one for AES or Blowfish) using a triple DES-CBC key derived 403 from the passphrase "All n-entities must communicate with other n- 404 entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12} 405 using 500 iterations of PBKDF2. 407 PKCS #5v2 values: 409 input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D 410 passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 411 77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74 412 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 413 74 69 74 65 65 68 65 65 68 65 65 73 414 "All n-entities must communicate with other " 415 "n-entities via n-1 entiteeheehees" 416 input 417 salt: 12 34 56 78 78 56 34 12 418 iterations: 500 420 output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 421 3DES key: 07 12 63 80 CC 47 AB 2D 423 CEK formatting phase: 425 length byte: 20 426 key check: 73 9C 82 427 CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 428 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B 429 padding: FA 06 0A 45 431 complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 432 CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 433 C7 1B AF 3B FA 06 0A 45 435 Key wrap phase (wrap CEK block using 3DES key): 437 IV: BA F1 CA 79 31 21 3C 4E 439 first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD 440 pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 441 96 9E 65 27 9E 12 6A EB 443 second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 444 pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 445 EC 74 E6 CA D7 DB 26 0C 447 ASN.1 encoded PasswordRecipientInfo: 449 0 A3 96: [3] { 450 2 02 1: INTEGER 0 451 5 A0 27: [0] { 452 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 453 18 30 14: SEQUENCE { 454 20 04 8: OCTET STRING 455 : 12 34 56 78 78 56 34 12 456 30 02 2: INTEGER 500 457 : } 458 : } 459 34 30 35: SEQUENCE { 460 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK (1 2 840 113549 1 9 16 3 9) 461 34 30 20: SEQUENCE { 462 36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) 463 46 04 8: OCTET STRING 464 : BA F1 CA 79 31 21 3C 4E 465 : } 466 : } 467 71 04 40: OCTET STRING 468 : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 469 : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 470 : EC 74 E6 CA D7 DB 26 0C 471 : } 473 4. Security Considerations 475 The security of this recipient information type rests on the security 476 of the underlying mechanisms employed, for which further information 477 can be found in RFC 2640 and PKCS5v2. More importantly, however, when 478 used with a password the security of this information type rests on the 479 entropy of the user-selected password, which is typically quite low. 480 Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, 481 although it should be recognized that even with pass phrases it will be 482 difficult to use this recipient information type to derive a KEK with 483 sufficient entropy to properly protect a 128-bit (or higher) CEK. 485 5. IANA Considerations 487 The PasswordRecipientInfo key encryption algorithms are identified by 488 object identifiers (OIDs). OIDs were assigned from an arc contributed 489 to the S/MIME Working Group by the RSA Security. Should additional 490 compression algorithms be introduced, the advocates for such algorithms 491 are expected to assign the necessary OIDs from their own arcs. No 492 action by the IANA is necessary for this document or any anticipated 493 updates. 495 Acknowledgments 497 The author would like to thank Jim Schaad, Phil Griffin, and the 498 members of the S/MIME Working Group for their comments and feedback on 499 this document. 501 Author Address 503 Peter Gutmann 504 University of Auckland 505 Private Bag 92019 506 Auckland, New Zealand 507 pgut001@cs.auckland.ac.nz 509 References 511 ASN1 CCITT Recommendation X.208: Specification of Abstract Syntax 512 Notation One (ASN.1), 1988. 514 RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels, 515 S.Bradner, March 1997. 517 RFC2630 Cryptographic Message Syntax, R.Housley, June 1999. 519 RFC2898 PKCS #5: Password-Based Cryptography Specification, Version 520 2.0, B.Kaliski, September 2000. 522 PACKAGE All-or-Nothing Encryption and the Package Transform, 523 R.Rivest, Proceedings of Fast Software Encryption '97, Haifa, 524 Israel, January 1997. 526 Appendix A: ASN.1:1988 Module 528 PasswordRecipientInfo-88 529 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 530 smime(16) modules(0) pwri(17) } 532 DEFINITIONS IMPLICIT TAGS ::= 533 BEGIN 535 IMPORTS 537 AlgorithmIdentifier 538 FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) 539 authenticationFramework(7) 3 } 541 CMSVersion, EncryptedKey 542 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 543 rsadsi(113549) pkcs(1) pkcs-9(9) 544 smime(16) modules(0) cms(1) }; 546 -- The following PDU is defined in PKCS5 { iso(1) member-body(2) 547 -- us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16) 548 -- pkcs5v2-0(1) }, however it can't be imported because because 549 -- it's specified in 1994/1997 ASN.1. Because of this it's copied 550 -- here from the source but rephrased as 1988 ASN.1. Further 551 -- details are given in [RFC 2898]. 553 PBKDF2-params ::= SEQUENCE { 554 salt OCTET STRING, 555 iterationCount INTEGER (1..MAX), 556 keyLength INTEGER (1..MAX) OPTIONAL, 557 prf AlgorithmIdentifier 558 DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } } 560 -- The PRF algorithm is also defined in PKCS5 and can neither be 561 -- imported nor expressed in 1988 ASN.1, however it is encoded as 562 -- an AlgorithmIdentifier with the OID: 564 id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 565 us(840) rsadsi(113549) digestAlgorithm(2) 7 } 567 -- and NULL parameters. Further details are given in [RFC 2898]. 569 -- Implementation note: Because of the inability to precisely 570 -- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it is 571 -- likely that implementors will also encounter alternative 572 -- interpretations of these parameters, usually using an alternate 573 -- OID from the IPsec arc which is generally used for HMAC-SHA1: 574 -- 575 -- hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) 576 -- identified-organization(3) dod(6) internet(1) security(5) 577 -- mechanisms(5) 8 1 2 } 578 -- 579 -- with absent (rather than NULL) parameters. 581 -- The PasswordRecipientInfo 583 id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2) 584 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 } 586 PasswordRecipientInfo ::= SEQUENCE { 587 version CMSVersion, -- Always set to 0 588 keyDerivationAlgorithm 589 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 590 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 591 encryptedKey EncryptedKey } 593 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 595 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 597 END -- PasswordRecipientInfo-88 -- 599 Appendix B: ASN.1:1997 Module 601 This appendix contains the same information as Appendix A in a more 602 recent (and precise) ASN.1 notation, however Appendix A takes 603 precedence in case of conflict. 605 PasswordRecipientInfo-97 606 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 607 smime(16) modules(0) pwri(18) } 609 DEFINITIONS IMPLICIT TAGS ::= 610 BEGIN 612 IMPORTS 614 id-PBKDF2, PBKDF2-params, 615 FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 616 pkcs-5(5) } 618 CMSVersion, EncryptedKey, des-ede3-cbc, CBCParameter 619 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 620 rsadsi(113549) pkcs(1) pkcs-9(9) 621 smime(16) modules(0) cms(1) }; 623 id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2) 624 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 } 626 PasswordRecipientInfo ::= SEQUENCE { 627 version CMSVersion, -- Always set to 0 628 keyDerivationAlgorithm 629 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 630 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 631 encryptedKey EncryptedKey } 633 KeyDerivationAlgorithmIdentifier ::= 634 AlgorithmIdentifier {{ KeyDerivationAlgorithms }} 636 KeyDerivationAlgorithms ALGORITHM ::= { 637 { OID id-PBKDF2 PARMS PBKDF2-params }, 638 ... 639 } 641 KeyEncryptionAlgorithmIdentifier ::= 642 AlgorithmIdentifier {{ KeyEncryptionAlgorithms }} 644 KeyEncryptionAlgorithms ALGORITHM ::= { 645 { OID id-alg-PWRI-KEK PARMS 646 AlgorithmIdentifier {{ PWRIAlgorithms }} }, 647 ... 648 } 650 -- Algorithm identifiers for algorithms used with the 651 -- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is a 652 -- MUST, all others are optional 654 PWRIAlgorithms ALGORITHM ::= { 655 { OID des-ede3-cbc PARMS CBCParameter }, 656 ... 657 } 659 -- Supporting definitions. We could also pull in the 660 -- AlgorithmIdentifier from an appropriately recent X.500 module (or 661 -- wherever) but it's just as easy (and more convenient for readers) 662 -- to provide a definition here 664 AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { 665 algorithm ALGORITHM.&id({IOSet}), 666 parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL 667 } 669 ALGORITHM ::= CLASS { 670 &id OBJECT IDENTIFIER UNIQUE, 671 &Type OPTIONAL 672 } 673 WITH SYNTAX { OID &id [PARMS &Type] } 675 END -- PasswordRecipientInfo-97 -- 677 Full Copyright Statement 679 Copyright (C) The Internet Society 2001. All Rights Reserved. 681 This document and translations of it may be copied and furnished to 682 others, and derivative works that comment on or otherwise explain it or 683 assist in its implementation may be prepared, copied, published and 684 distributed, in whole or in part, without restriction of any kind, 685 provided that the above copyright notice and this paragraph are 686 included on all such copies and derivative works. However, this 687 document itself may not be modified in any way, such as by removing the 688 copyright notice or references to the Internet Society or other 689 Internet organizations, except as needed for the purpose of developing 690 Internet standards in which case the procedures for copyrights defined 691 in the Internet Standards process must be followed, or as required to 692 translate it into languages other than English. 694 The limited permissions granted above are perpetual and will not be 695 revoked by the Internet Society or its successors or assigns. 697 This document and the information contained herein is provided on an 698 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 699 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 700 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 701 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 702 FITNESS FOR A PARTICULAR PURPOSE.