summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3211.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3211.txt')
-rw-r--r--doc/rfc/rfc3211.txt955
1 files changed, 955 insertions, 0 deletions
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]
+