RFC 3211

Password-based Encryption for CMS 🔐

okay bestie, let's get into RFC 3211 🎀 It's by P. Gutmann from the University of Auckland, filed under the Network Working Group. Its category is Standards Track and the date is December 2001. The title block doesn't list anything it obsoletes or updates, so this one is standing on its own 💅

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 🫶 For the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨

Copyright Notice ©️

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

Abstract 🌸

This document gives us a way to encrypt data using passwords that users supply, and by extension, any kind of variable-length keying material that isn't necessarily a fixed-format key for one specific algorithm 🧚 The thing is, CMS (the Cryptographic Message Syntax data format) doesn't have any provisions for password-based data encryption yet, so this fills that gap. Iconic behaviour ngl 👑

1. Introduction ✨

This document describes a password-based content encryption mechanism for CMS. It's implemented as a new RecipientInfo type, and it's an extension to the RecipientInfo types already defined in RFC 2630 🦋

The message formats 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. These are the rules for reading all the capitals in here, so pay attention 🙈

1.1 Password-based Content Encryption 🔐

CMS already defined three recipient information types. There's one for public-key key wrapping (KeyTransRecipientInfo), one for conventional key wrapping (KEKRecipientInfo), and one for key agreement (KeyAgreeRecipientInfo). The recipient information in this document adds a fourth type, PasswordRecipientInfo, which handles password-based key wrapping. It's giving main character energy 💅

1.2 RecipientInfo Types 🌈

This new recipient information type extends the RecipientInfo type defined in section 6.2 of CMS, so the types now look like this:

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  kekri [2] KEKRecipientInfo,
  pwri [3] PasswordRecipientinfo   -- New RecipientInfo type
  }

Even though the recipient information generation process is described in terms of a password-based operation (since that's going to be its most common use), the transformation is actually a general-purpose key derivation one. It lets any type of keying material get converted into a key for one specific content-encryption algorithm 🫶 Also, the most common use of password-based encryption is locking up files stored on your own machine, not sending stuff across a network. So the word "recipient" is kinda misleading, but it's used here anyway because the other key transport mechanisms have always been described in similar terms 🙃

1.2.1 PasswordRecipientInfo Type 🎀

Recipient information that uses a user-supplied password, or a previously agreed-upon key, is represented in the type PasswordRecipientInfo. Each instance of PasswordRecipientInfo transfers the content-encryption key (CEK) to one or more recipients who already 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 }

Here's what each field of PasswordRecipientInfo means:

• version is the syntax version number. It MUST be 0. You can find the details of the CMSVersion type in CMS [RFC2630], section 10.2.5 📖
• keyDerivationAlgorithm identifies the key-derivation algorithm, along with any associated parameters, that gets used to derive the KEK from the user-supplied password. If this field is absent, the KEK comes from an external source instead, like a crypto token such as a smart card 💳
• keyEncryptionAlgorithm identifies the key-encryption algorithm, along with any associated parameters, that gets 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 happens in two stages. In the first stage, a user-supplied password gets converted into a KEK if that's needed. In the second stage, the KEK is used to encrypt a CEK. These two stages are identified by the two algorithm identifiers 🧩 The PKCS #5v2 standard [RFC2898] goes one step further and wraps both up into a single algorithm identifier. But that design is specific to that standard and may not work for other key wrapping mechanisms, so this document specifies the two steps separately.

Right now the format doesn't have any way to tell apart multiple password recipient infos. That would come up if, say, two passwords were used to encrypt the same data 🥺 Typical applications just encrypt data like a file with one password from the user, so there isn't much existing practice to learn from. Without clear requirements, an appropriate multiple-password mechanism would be difficult (maybe even impossible) to define right now. If enough demand shows up, this might get addressed in a future version of this document, for example by adding an optional identification field of some appropriate form 🌟

2 Supported Algorithms 💖

This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included 🎀

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 has a more precise definition of the allowed algorithm type than you can get with 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 key encryption algorithm identifier for PasswordRecipientInfo 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 key wrap algorithm specified in section 2.3 🎁

There's no requirement that the CEK algorithm match the KEK encryption algorithm. Still, care should be taken to make sure 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 💡

Using a level of indirection in specifying the KeyEncryptionAlgorithmIdentifier lets alternative wrapping algorithms get used in the future. If the KEK algorithm were specified directly in this field, then using any alternative wrapping algorithm would require a change to the PasswordRecipientInfo structure, not just a change to the key encryption algorithm identifier. That would be a whole thing 🙄

The parameter field for this algorithm identifier could default to triple-DES. But because of 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 way that makes sure every bit of plaintext affects every bit of ciphertext. That makes it equivalent in function to the package transform [PACKAGE], without needing extra mechanisms or resources like hash functions or cryptographically strong random numbers 🪄 The algorithm runs in two phases. The first phase formats the CEK into a form that's suitable for encryption by the KEK. The second phase wraps the formatted CEK using the KEK.

Key formatting: create a formatted CEK block made up 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 doesn't 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 like this:

CEK byte count || check value || CEK || padding (if required)

Key wrapping:

1. Encrypt the padded key using the KEK.
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 ✨

okay so let's walk through a real example, bestie 🫶 say the content-encryption algorithm is Skipjack and the KEK algorithm is Triple-DES. Here's how wrapping goes:

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, encrypt the padded Skipjack key.
3. Without resetting the IV, encrypt the encrypted padded key a second time.

And the unwrap steps are the mirror image 🪞✨:

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 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.

the KEK check in step 4 is how you find out you've got the wrong key, so don't skip it 💀

2.3.4 Rationale for the Double Wrapping 💅

okay this part is giving math-nerd energy and I'm here for it 🤓. If lots of CEKs get encrypted the normal way with the same KEK, and that KEK has a 64-bit block size, then after about 2^32 encryptions you're very likely to get a collision between blocks of encrypted CEKs. And if an opponent manages to grab one CEK, they might be able to work out other CEKs from that. The double-encryption wrapping makes every bit of ciphertext depend on every bit of the CEK, which kills that collision problem. It also stops other sneaky stuff like bit-flipping attacks 🙅‍♀️. Since the IV is applied to the inner layer, wrapping the same CEK with the same KEK still gives you a completely different wrapped key every single time 🦋.

Another bonus is that double wrapping doesn't need any extra algorithms, like hash algorithms, on top of the wrapping algorithm itself. That means it can run on devices that only support one type of encryption algorithm 🧚. A classic example is a crypto token like a smart card, which often has just a single block cipher and a single public-key algorithm. If wrapping needed another algorithm, those devices would be completely stuck 😭.

3. Test Vectors 🧪

this section has two sets of test vectors, and they have very different vibes 💖. The first is a very basic set for DES. It's great for checking correctness, and it uses an algorithm that's freely exportable from the US 🇺🇸. The second is a stress-test version with super long passphrase and key sizes and a mix of algorithms, so you can check how things behave in extreme cases 🌋.

The basic test has two subtests: a known-answer test for the key derivation stage, and a full test of the key wrapping. Both 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 (which is the same as using ECB), and it's used to encrypt an all-zero data block 🫧.

Here's what you get 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

And here's what you get 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:

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
           :   }

now the stress test 🔥. This one wraps a 256-bit key (the kind you'd use for AES or Blowfish) using a triple DES-CBC key. That key is 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 } and 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

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 🔐

this is the serious bit, so listen up 👀. The security of this recipient information type depends on the security of the underlying mechanisms it uses. You can find more on those in RFC 2630 and PKCS5v2. But the really important part is this: when you use a password, the security depends on how much entropy the user's password has, and that's usually pretty low 😬. Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED. Even so, it should be recognized that even with pass phrases, it's hard to use this recipient information type to derive a KEK with enough entropy to properly protect a 128-bit (or higher) CEK 💀.

5. IANA Considerations

the PasswordRecipientInfo key encryption algorithms are identified by object identifiers (OIDs). Those OIDs were assigned from an arc that RSA Security contributed to the S/MIME Working Group. If more encryption algorithms come along later, their advocates are expected to assign the OIDs they need 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.

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:

--
-- 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 --

Okay, so the old 1988 version is done 💅 and now we're on to the fancier one, bestie 🎀

Appendix B: ASN.1:1997 Module ✨

This appendix says the same stuff as Appendix A, just in a newer and more precise ASN.1 notation 🧚 But if the two ever disagree, Appendix A wins 👑

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) };

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,
  &Type            OPTIONAL
  }
  WITH SYNTAX { OID &id [PARMS &Type] }

END  -- PasswordRecipientInfo-97 --

---

Full Copyright Statement

Okay, legal bestie moment 🫶 Copyright (C) The Internet Society (2001). All Rights Reserved.

Anyone can copy this document and hand it out, and translations of it too. You can also write derivative works that comment on it, explain it, or help people implement it, then prepare, copy, publish, and distribute those in whole or in part with no restrictions of any kind 🦋 The one catch is that the above copyright notice and this paragraph have to be on every single copy and derivative work.

But the document itself can't be modified in any way 🙈 That means no removing the copyright notice, and no removing references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards (then the copyright procedures in the Internet Standards process must be followed) or when it's being translated into a language other than English 🌈

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💜

This document and the information in it 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. 🌸✨