From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3211.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc3211.txt (limited to 'doc/rfc/rfc3211.txt') diff --git a/doc/rfc/rfc3211.txt b/doc/rfc/rfc3211.txt new file mode 100644 index 0000000..1e03b6d --- /dev/null +++ b/doc/rfc/rfc3211.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group P. Gutmann +Request for Comments: 3211 University of Auckland +Category: Standards Track December 2001 + + + Password-based Encryption for CMS + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document provides a method of encrypting data using user- + supplied passwords and, by extension, any form of variable-length + keying material which is not necessarily an algorithm-specific + fixed-format key. The Cryptographic Message Syntax data format does + not currently contain any provisions for password-based data + encryption. + +1. Introduction + + This document describes a password-based content encryption mechanism + for CMS. This is implemented as a new RecipientInfo type and is an + extension to the RecipientInfo types currently defined in RFC 2630. + + The format of the messages are described in ASN.1 [ASN1]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be + interpreted as described in RFC 2119. + + + + + + + + + + + + +Gutmann Standards Track [Page 1] + +RFC 3211 Password-based Encryption for CMS December 2001 + + +1.1 Password-based Content Encryption + + CMS currently defined three recipient information types for public- + key key wrapping (KeyTransRecipientInfo), conventional key wrapping + (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The + recipient information described here adds a fourth type, + PasswordRecipientInfo, which provides for password-based key + wrapping. + +1.2 RecipientInfo Types + + The new recipient information type is an extension to the + RecipientInfo type defined in section 6.2 of CMS, extending the types + to: + + RecipientInfo ::= CHOICE { + ktri KeyTransRecipientInfo, + kari [1] KeyAgreeRecipientInfo, + kekri [2] KEKRecipientInfo, + pwri [3] PasswordRecipientinfo -- New RecipientInfo type + } + + Although the recipient information generation process is described in + terms of a password-based operation (since this will be its most + common use), the transformation employed is a general-purpose key + derivation one which allows any type of keying material to be + converted into a key specific to a particular content-encryption + algorithm. Since the most common use for password-based encryption + is to encrypt files which are stored locally (rather than being + transmitted across a network), the term "recipient" is somewhat + misleading, but is used here because the other key transport + mechanisms have always been described in similar terms. + +1.2.1 PasswordRecipientInfo Type + + Recipient information using a user-supplied password or previously + agreed-upon key is represented in the type PasswordRecipientInfo. + Each instance of PasswordRecipientInfo will transfer the content- + encryption key (CEK) to one or more recipients who have the + previously agreed-upon password or key-encryption key (KEK). + + PasswordRecipientInfo ::= SEQUENCE { + version CMSVersion, -- Always set to 0 + keyDerivationAlgorithm + [0] KeyDerivationAlgorithmIdentifier OPTIONAL, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + + + + +Gutmann Standards Track [Page 2] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + The fields of type PasswordRecipientInfo have the following meanings: + + version is the syntax version number. It MUST be 0. Details of + the CMSVersion type are discussed in CMS [RFC2630], section + 10.2.5. + + keyDerivationAlgorithm identifies the key-derivation algorithm, + and any associated parameters, used to derive the KEK from the + user-supplied password. If this field is absent, the KEK is + supplied from an external source, for example a crypto token such + as a smart card. + + keyEncryptionAlgorithm identifies the key-encryption algorithm, + and any associated parameters, used to encrypt the CEK with the + KEK. + + encryptedKey is the result of encrypting the content-encryption + key with the KEK. + +1.2.2 Rationale + + Password-based key wrapping is a two-stage process, a first stage in + which a user-supplied password is converted into a KEK if required, + and a second stage in which the KEK is used to encrypt a CEK. These + two stages are identified by the two algorithm identifiers. Although + the PKCS #5v2 standard [RFC2898] goes one step further to wrap these + up into a single algorithm identifier, this design is particular to + that standard and may not be applicable for other key wrapping + mechanisms. For this reason the two steps are specified separately. + + The current format doesn't provide any means of differentiating + between multiple password recipient infos, which would occur for + example if two passwords are used to encrypt the same data. + Unfortunately there is a lack of existing practice in this area, + since typical applications follow the model of encrypting data such + as a file with a single password obtained from the user. Without any + clear requirements, an appropriate multiple password mechanism would + be difficult (perhaps impossible) to define at this time. If + sufficient demand emerges then this may be addressed in a future + version of this document, for example by adding an optional + identification field of an appropriate form. + +2 Supported Algorithms + + This section lists the algorithms that must be implemented. + Additional algorithms that should be implemented are also included. + + + + + +Gutmann Standards Track [Page 3] + +RFC 3211 Password-based Encryption for CMS December 2001 + + +2.1 Key Derivation Algorithms + + These algorithms are used to convert the password into a KEK. The + key derivation algorithms are: + + KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier + + Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B + contains a more precise definition of the allowed algorithm type than + is possible using 1988 ASN.1. + +2.2 Key Encryption Algorithms + + These algorithms are used to encrypt the CEK using the derived KEK. + The key encryption algorithms are: + + KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + + The PasswordRecipientInfo key encryption algorithm identifier is: + + id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 } + + The AlgorithmIdentifier parameters field for this algorithm contains + the KEK encryption algorithm used with the the key wrap algorithm + specified in section 2.3. + + There is no requirement that the CEK algorithm match the KEK + encryption algorithm, although care should be taken to ensure that, + if different algorithms are used, they offer an equivalent level of + security (for example wrapping a Triple-DES key with an RC2/40 key + leads to a severe impedance mismatch in encryption strength). + + Conforming implementations MUST implement the id-alg-PWRI-KEK key + wrap algorithm. For the KEK encryption algorithms used by id-alg- + PWRI-KEK, conforming implementations MUST include Triple-DES in CBC + mode and MAY include other algorithms such as AES, CAST-128, RC5, + IDEA, Skipjack, Blowfish, and encryption modes as required. + Implementations SHOULD NOT include any KSG (keystream generator) + ciphers such as RC4 or a block cipher in OFB mode, and SHOULD NOT + include a block cipher in ECB mode. + +2.2.1 Rationale + + The use of a level of indirection in specifying the + KeyEncryptionAlgorithmIdentifier allows alternative wrapping + algorithms to be used in the future. If the KEK algorithm were + specified directly in this field then any use of an alternative + + + +Gutmann Standards Track [Page 4] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + wrapping algorithm would require a change to the + PasswordRecipientInfo structure rather than simply a change to the + key encryption algorithm identifier. + + The parameter field for this algorithm identifier could be specified + to default to triple-DES, however due to the confusion over NULL vs + absent parameters in algorithm identifiers it's left explicit with no + default value. + +2.3.1 Key Wrap + + The key wrap algorithm encrypts a CEK with a KEK in a manner which + ensures that every bit of plaintext effects every bit of ciphertext. + This makes it equivalent in function to the package transform + [PACKAGE] without requiring additional mechanisms or resources such + as hash functions or cryptographically strong random numbers. The + key wrap algorithm is performed in two phases, a first phase which + formats the CEK into a form suitable for encryption by the KEK, and a + second phase which wraps the formatted CEK using the KEK. + + Key formatting: Create a formatted CEK block consisting of the + following: + + 1. A one-byte count of the number of bytes in the CEK. + + 2. A check value containing the bitwise complement of the first + three bytes of the CEK. + + 3. The CEK. + + 4. Enough random padding data to make the CEK data block a + multiple of the KEK block length and at least two KEK cipher + blocks long (the fact that 32 bits of count+check value are + used means that even with a 40-bit CEK, the resulting data size + will always be at least two (64-bit) cipher blocks long). The + padding data does not have to be cryptographically strong, + although unpredictability helps. Note that PKCS #5 padding is + not used, since the length of the data is already known. + + The formatted CEK block then looks as follows: + + CEK byte count || check value || CEK || padding (if required) + + Key wrapping: + + 1. Encrypt the padded key using the KEK. + + + + + +Gutmann Standards Track [Page 5] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + 2. Without resetting the IV (that is, using the last ciphertext + block as the IV), encrypt the encrypted padded key a second + time. + + The resulting double-encrypted data is the EncryptedKey. + +2.3.2 Key Unwrap + + Key unwrapping: + + 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th + ciphertext block. + + 2. Using the decrypted n'th ciphertext block as the IV, decrypt + the 1st ... n-1'th ciphertext blocks. This strips the outer + layer of encryption. + + 3. Decrypt the inner layer of encryption using the KEK. + + Key format verification: + + 1a. If the CEK byte count is less than the minimum allowed key + size (usually 5 bytes for 40-bit keys) or greater than the + wrapped CEK length or not valid for the CEK algorithm (eg not + 16 or 24 bytes for triple DES), the KEK was invalid. + + 1b. If the bitwise complement of the key check value doesn't match + the first three bytes of the key, the KEK was invalid. + +2.3.3 Example + + Given a content-encryption algorithm of Skipjack and a KEK algorithm + of Triple-DES, the wrap steps are as follows: + + 1. Set the first 4 bytes of the CEK block to the Skipjack key size + (10 bytes) and the bitwise complement of the first three bytes + of the CEK. + + 2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to + 16 bytes (two triple-DES blocks) using 2 bytes of random data. + + 2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, + encrypted the padded Skipjack key. + + 3. Without resetting the IV, encrypt the encrypted padded key a + second time. + + + + + +Gutmann Standards Track [Page 6] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + The unwrap steps are as follows: + + 1. Using the first 8 bytes of the double-encrypted key as the IV, + decrypt the second 8 bytes. + + 2. Without resetting the IV, decrypt the first 8 bytes. + + 3. Decrypt the inner layer of encryption using the the IV given in + the KeyEncryptionAlgorithmIdentifer to recover the padded + Skipjack key. + + 4. If the length byte isn't equal to the Skipjack key size (80 + bits or 10 bytes) or the bitwise complement of the check bytes + doesn't match the first three bytes of the CEK, the KEK was + invalid. + +2.3.4 Rationale for the Double Wrapping + + If many CEKs are encrypted in a standard way with the same KEK and + the KEK has a 64-bit block size then after about 2^32 encryptions + there is a high probability of a collision between different blocks + of encrypted CEKs. If an opponent manages to obtain a CEK, they may + be able to solve for other CEKs. The double-encryption wrapping + process, which makes every bit of ciphertext dependent on every bit + of the CEK, eliminates this collision problem (as well as preventing + other potential problems such as bit-flipping attacks). Since the IV + is applied to the inner layer of encryption, even wrapping the same + CEK with the same KEK will result in a completely different wrapped + key each time. + + An additional feature of the double wrapping is that it doesn't + require the use of any extra algorithms such as hash algorithms in + addition to the wrapping algorithm itself, allowing it to be + implemented in devices which only support one type of encryption + algorithm. A typical example of such a device is a crypto token such + as a smart card which often only supports a single block cipher and a + single public-key algorithm, making it impossible to wrap keys if the + use of an additional algorithm were required. + +3. Test Vectors + + This section contains two sets of test vectors, a very basic set for + DES which can be used to verify correctness and which uses an + algorithm which is freely exportable from the US, and a stress-test + version which uses very long passphrase and key sizes and a mixture + of algorithms which can be used to verify the behaviour in extreme + cases. + + + + +Gutmann Standards Track [Page 7] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + The basic test contains two subtests, a known-answer test for the key + derivation stage and a full test of the key wrapping. Both tests use + a DES-CBC key derived from the password "password" with salt { 12 34 + 56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known + answer test the IV is set to all zeroes (equivalent to using ECB) and + used to encrypt an all-zero data block. + + The following values are obtained for the known-answer test: + + PKCS #5v2 values: + + input 70 61 73 73 77 6f 72 64 + passphrase: "password" + input salt: 12 34 56 78 78 56 34 12 + iterations: 5 + + output key: D1 DA A7 86 15 F2 87 E6 + known answer: 9B BD 78 FC 11 A3 A9 08 + + The following values are obtained when wrapping a 64-bit (parity- + adjusted) DES-EBC key: + + PKCS #5v2 values: + + input 70 61 73 73 77 6f 72 64 + passphrase: "password" + input salt: 12 34 56 78 78 56 34 12 + iterations: 5 + + output key: D1 DA A7 86 15 F2 87 E6 + + CEK formatting phase: + + length byte: 08 + key check: 73 9D 83 + CEK: 8C 62 7C 89 73 23 A2 F8 + padding: C4 36 F5 41 + + complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 + CEK block: + + + + + + + + + + + +Gutmann Standards Track [Page 8] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + Key wrap phase (wrap CEK block using DES key): + + IV: EF E5 98 EF 21 B3 3D 6D + + first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4 + pass output: + second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 + pass output: + + ASN.1 encoded PasswordRecipientInfo: + + 0 A3 68: [3] { + 2 02 1: INTEGER 0 + 5 A0 26: [0] { + 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) + 18 30 13: SEQUENCE { + 20 04 8: OCTET STRING + : 12 34 56 78 78 56 34 12 + 30 02 1: INTEGER 5 + : } + : } + 34 30 32: SEQUENCE { + 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK + : (1 2 840 113549 1 9 16 3 9) + 33 30 17: SEQUENCE { + 35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7) + 42 04 8: OCTET STRING + : EF E5 98 EF 21 B3 3D 6D + : } + : } + 68 04 16: OCTET STRING + : B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 + : } + + + + + + + + + + + + + + + + + + +Gutmann Standards Track [Page 9] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + The following values are obtained when wrapping a 256-bit key (for + example one for AES or Blowfish) using a triple DES-CBC key derived + from the passphrase "All n-entities must communicate with other + n-entities via n-1 entiteeheehees" with salt + { 12 34 56 78 78 56 34 12 } using 500 iterations of PBKDF2. + + PKCS #5v2 values: + + input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D + passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 + 77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74 + 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E + 74 69 74 65 65 68 65 65 68 65 65 73 + "All n-entities must communicate with other " + "n-entities via n-1 entiteeheehees" + input + salt: 12 34 56 78 78 56 34 12 + iterations: 500 + + output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 + 3DES key: 07 12 63 80 CC 47 AB 2D + + CEK formatting phase: + + length byte: 20 + key check: 73 9C 82 + CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 + D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B + padding: FA 06 0A 45 + + complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB + CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 + C7 1B AF 3B FA 06 0A 45 + + Key wrap phase (wrap CEK block using 3DES key): + + IV: BA F1 CA 79 31 21 3C 4E + + first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD + pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 + 96 9E 65 27 9E 12 6A EB + + second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 + pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 + EC 74 E6 CA D7 DB 26 0C + + + + + + +Gutmann Standards Track [Page 10] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + ASN.1 encoded PasswordRecipientInfo: + + 0 A3 96: [3] { + 2 02 1: INTEGER 0 + 5 A0 27: [0] { + 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) + 18 30 14: SEQUENCE { + 20 04 8: OCTET STRING + : 12 34 56 78 78 56 34 12 + 30 02 2: INTEGER 500 + : } + : } + 34 30 35: SEQUENCE { + 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK + : (1 2 840 113549 1 9 16 3 9) + 34 30 20: SEQUENCE { + 36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) + 46 04 8: OCTET STRING + : BA F1 CA 79 31 21 3C 4E + : } + : } + 71 04 40: OCTET STRING + : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 + : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 + : EC 74 E6 CA D7 DB 26 0C + : } + +4. Security Considerations + + The security of this recipient information type rests on the security + of the underlying mechanisms employed, for which further information + can be found in RFC 2630 and PKCS5v2. More importantly, however, + when used with a password the security of this information type rests + on the entropy of the user-selected password, which is typically + quite low. Pass phrases (as opposed to simple passwords) are + STRONGLY RECOMMENDED, although it should be recognized that even with + pass phrases it will be difficult to use this recipient information + type to derive a KEK with sufficient entropy to properly protect a + 128-bit (or higher) CEK. + + + + + + + + + + + + +Gutmann Standards Track [Page 11] + +RFC 3211 Password-based Encryption for CMS December 2001 + + +5. IANA Considerations + + The PasswordRecipientInfo key encryption algorithms are identified by + object identifiers (OIDs). OIDs were assigned from an arc + contributed to the S/MIME Working Group by the RSA Security. Should + additional encryption algorithms be introduced, the advocates for + such algorithms are expected to assign the necessary OIDs from their + own arcs. No action by the IANA is necessary for this document or + any anticipated updates. + +Acknowledgments + + The author would like to thank Jim Schaad, Phil Griffin, and the + members of the S/MIME Working Group for their comments and feedback + on this document. + +Author Address + + Peter Gutmann + University of Auckland + Private Bag 92019 + Auckland, New Zealand + + EMail: pgut001@cs.auckland.ac.nz + +References + + [ASN1] CCITT Recommendation X.208: Specification of Abstract + Syntax Notation One (ASN.1), 1988. + + [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June + 1999. + + [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography + Specification, Version 2.0", RFC 2898, September 2000. + + [PACKAGE] All-or-Nothing Encryption and the Package Transform, R. + Rivest, Proceedings of Fast Software Encryption '97, Haifa, + Israel, January 1997. + + + + + + + + + +Gutmann Standards Track [Page 12] + +RFC 3211 Password-based Encryption for CMS December 2001 + + +Appendix A: ASN.1:1988 Module + +PasswordRecipientInfo-88 + { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) + smime(16) modules(0) pwri(17) } + +DEFINITIONS IMPLICIT TAGS ::= +BEGIN + +IMPORTS + + AlgorithmIdentifier + FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) + authenticationFramework(7) 3 } + + CMSVersion, EncryptedKey + FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) + smime(16) modules(0) cms(1) }; + +-- The following PDU is defined in PKCS5 { iso(1) member-body(2) +-- us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16) +-- pkcs5v2-0(1) }, however it can't be imported because because +-- it's specified in 1994/1997 ASN.1. Because of this it's copied +-- here from the source but rephrased as 1988 ASN.1. Further +-- details are given in [RFC 2898]. + +PBKDF2-params ::= SEQUENCE { + salt OCTET STRING, + iterationCount INTEGER (1..MAX), + keyLength INTEGER (1..MAX) OPTIONAL, + prf AlgorithmIdentifier + DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } } + +-- The PRF algorithm is also defined in PKCS5 and can neither be +-- imported nor expressed in 1988 ASN.1, however it is encoded as +-- an AlgorithmIdentifier with the OID: + +id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) digestAlgorithm(2) 7 } + +-- and NULL parameters. Further details are given in [RFC 2898]. + +-- Implementation note: Because of the inability to precisely +-- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it is +-- likely that implementors will also encounter alternative +-- interpretations of these parameters, usually using an alternate +-- OID from the IPsec arc which is generally used for HMAC-SHA1: + + + +Gutmann Standards Track [Page 13] + +RFC 3211 Password-based Encryption for CMS December 2001 + + +-- +-- hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) +-- identified-organization(3) dod(6) internet(1) security(5) +-- mechanisms(5) 8 1 2 } +-- +-- with absent (rather than NULL) parameters. + +-- The PasswordRecipientInfo + +id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 } + +PasswordRecipientInfo ::= SEQUENCE { + version CMSVersion, -- Always set to 0 + keyDerivationAlgorithm + [0] KeyDerivationAlgorithmIdentifier OPTIONAL, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + +KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier + +KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + +END -- PasswordRecipientInfo-88 -- + +Appendix B: ASN.1:1997 Module + +This appendix contains the same information as Appendix A in a more +recent (and precise) ASN.1 notation, however Appendix A takes +precedence in case of conflict. + +PasswordRecipientInfo-97 + { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) + smime(16) modules(0) pwri(18) } + +DEFINITIONS IMPLICIT TAGS ::= +BEGIN + +IMPORTS + + id-PBKDF2, PBKDF2-params, + FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-5(5) } + + CMSVersion, EncryptedKey, des-ede3-cbc, CBCParameter + FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) + smime(16) modules(0) cms(1) }; + + + +Gutmann Standards Track [Page 14] + +RFC 3211 Password-based Encryption for CMS December 2001 + + +id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 } + +PasswordRecipientInfo ::= SEQUENCE { + version CMSVersion, -- Always set to 0 + keyDerivationAlgorithm + [0] KeyDerivationAlgorithmIdentifier OPTIONAL, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + +KeyDerivationAlgorithmIdentifier ::= + AlgorithmIdentifier {{ KeyDerivationAlgorithms }} + +KeyDerivationAlgorithms ALGORITHM ::= { + { OID id-PBKDF2 PARMS PBKDF2-params }, + ... + } + +KeyEncryptionAlgorithmIdentifier ::= + AlgorithmIdentifier {{ KeyEncryptionAlgorithms }} + +KeyEncryptionAlgorithms ALGORITHM ::= { + { OID id-alg-PWRI-KEK PARMS + AlgorithmIdentifier {{ PWRIAlgorithms }} }, + ... + } + +-- Algorithm identifiers for algorithms used with the +-- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is a +-- MUST, all others are optional + +PWRIAlgorithms ALGORITHM ::= { + { OID des-ede3-cbc PARMS CBCParameter }, + ... + } + +-- Supporting definitions. We could also pull in the +-- AlgorithmIdentifier from an appropriately recent X.500 module (or +-- wherever) but it's just as easy (and more convenient for readers) +-- to provide a definition here + +AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { + algorithm ALGORITHM.&id({IOSet}), + parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL + } + +ALGORITHM ::= CLASS { + &id OBJECT IDENTIFIER UNIQUE, + + + +Gutmann Standards Track [Page 15] + +RFC 3211 Password-based Encryption for CMS December 2001 + + + &Type OPTIONAL + } + WITH SYNTAX { OID &id [PARMS &Type] } + +END -- PasswordRecipientInfo-97 -- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gutmann Standards Track [Page 16] + +RFC 3211 Password-based Encryption for CMS December 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Gutmann Standards Track [Page 17] + -- cgit v1.2.3