As per Relevance of the word december, we have this rfc below:
Network Working Group P.
Request for Comments: 3211 University of
Category: Standards Track December 2001
Password-based Encryption for
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document provides a method of encrypting data using user
supplied passwords and, by extension, any form of variable-
keying material which is not necessarily an algorithm-
fixed-format key. The Cryptographic Message Syntax data format
not currently contain any provisions for password-based
encryption
1.
This document describes a password-based content encryption
for CMS. This is implemented as a new RecipientInfo type and is
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
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
CMS currently defined three recipient information types for public
key key wrapping (KeyTransRecipientInfo), conventional key
(KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo).
recipient information described here adds a fourth type
PasswordRecipientInfo, which provides for password-based
wrapping
1.2 RecipientInfo
The new recipient information type is an extension to
RecipientInfo type defined in section 6.2 of CMS, extending the
to
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo
kari [1] KeyAgreeRecipientInfo
kekri [2] KEKRecipientInfo
pwri [3] PasswordRecipientinfo -- New RecipientInfo
}
Although the recipient information generation process is described
terms of a password-based operation (since this will be its
common use), the transformation employed is a general-purpose
derivation one which allows any type of keying material to
converted into a key specific to a particular content-
algorithm. Since the most common use for password-based
is to encrypt files which are stored locally (rather than
transmitted across a network), the term "recipient" is
misleading, but is used here because the other key
mechanisms have always been described in similar terms
1.2.1 PasswordRecipientInfo
Recipient information using a user-supplied password or
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
previously agreed-upon password or key-encryption key (KEK).
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
[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
the CMSVersion type are discussed in CMS [RFC2630],
10.2.5.
keyDerivationAlgorithm identifies the key-derivation algorithm
and any associated parameters, used to derive the KEK from
user-supplied password. If this field is absent, the KEK
supplied from an external source, for example a crypto token
as a smart card
keyEncryptionAlgorithm identifies the key-encryption algorithm
and any associated parameters, used to encrypt the CEK with
KEK
encryptedKey is the result of encrypting the content-
key with the KEK
1.2.2
Password-based key wrapping is a two-stage process, a first stage
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.
two stages are identified by the two algorithm identifiers.
the PKCS #5v2 standard [RFC2898] goes one step further to wrap
up into a single algorithm identifier, this design is particular
that standard and may not be applicable for other key
mechanisms. For this reason the two steps are specified separately
The current format doesn't provide any means of
between multiple password recipient infos, which would occur
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
as a file with a single password obtained from the user. Without
clear requirements, an appropriate multiple password mechanism
be difficult (perhaps impossible) to define at this time.
sufficient demand emerges then this may be addressed in a
version of this document, for example by adding an
identification field of an appropriate form
2 Supported
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
These algorithms are used to convert the password into a KEK.
key derivation algorithms are
KeyDerivationAlgorithmIdentifer ::=
Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix
contains a more precise definition of the allowed algorithm type
is possible using 1988 ASN.1.
2.2 Key Encryption
These algorithms are used to encrypt the CEK using the derived KEK
The key encryption algorithms are
KeyEncryptionAlgorithmIdentifier ::=
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
the KEK encryption algorithm used with the the key wrap
specified in section 2.3.
There is no requirement that the CEK algorithm match the
encryption algorithm, although care should be taken to ensure that
if different algorithms are used, they offer an equivalent level
security (for example wrapping a Triple-DES key with an RC2/40
leads to a severe impedance mismatch in encryption strength).
Conforming implementations MUST implement the id-alg-PWRI-KEK
wrap algorithm. For the KEK encryption algorithms used by id-alg
PWRI-KEK, conforming implementations MUST include Triple-DES in
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
include a block cipher in ECB mode
2.2.1
The use of a level of indirection in specifying
KeyEncryptionAlgorithmIdentifier allows alternative
algorithms to be used in the future. If the KEK algorithm
specified directly in this field then any use of an
Gutmann Standards Track [Page 4]
RFC 3211 Password-based Encryption for CMS December 2001
wrapping algorithm would require a change to
PasswordRecipientInfo structure rather than simply a change to
key encryption algorithm identifier
The parameter field for this algorithm identifier could be
to default to triple-DES, however due to the confusion over NULL
absent parameters in algorithm identifiers it's left explicit with
default value
2.3.1 Key
The key wrap algorithm encrypts a CEK with a KEK in a manner
ensures that every bit of plaintext effects every bit of ciphertext
This makes it equivalent in function to the package
[PACKAGE] without requiring additional mechanisms or resources
as hash functions or cryptographically strong random numbers.
key wrap algorithm is performed in two phases, a first phase
formats the CEK into a form suitable for encryption by the KEK, and
second phase which wraps the formatted CEK using the KEK
Key formatting: Create a formatted CEK block consisting of
following
1. A one-byte count of the number of bytes in the CEK
2. A check value containing the bitwise complement of the
three bytes of the CEK
3. The CEK
4. Enough random padding data to make the CEK data block
multiple of the KEK block length and at least two KEK
blocks long (the fact that 32 bits of count+check value
used means that even with a 40-bit CEK, the resulting data
will always be at least two (64-bit) cipher blocks long).
padding data does not have to be cryptographically strong
although unpredictability helps. Note that PKCS #5 padding
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
block as the IV), encrypt the encrypted padded key a
time
The resulting double-encrypted data is the EncryptedKey
2.3.2 Key
Key unwrapping
1. Using the n-1'th ciphertext block as the IV, decrypt the n'
ciphertext block
2. Using the decrypted n'th ciphertext block as the IV,
the 1st ... n-1'th ciphertext blocks. This strips the
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
size (usually 5 bytes for 40-bit keys) or greater than
wrapped CEK length or not valid for the CEK algorithm (eg
16 or 24 bytes for triple DES), the KEK was invalid
1b. If the bitwise complement of the key check value doesn't
the first three bytes of the key, the KEK was invalid
2.3.3
Given a content-encryption algorithm of Skipjack and a KEK
of Triple-DES, the wrap steps are as follows
1. Set the first 4 bytes of the CEK block to the Skipjack key
(10 bytes) and the bitwise complement of the first three
of the CEK
2. Append the 80-bit (10-byte) Skipjack CEK and pad the total
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
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
the KeyEncryptionAlgorithmIdentifer to recover the
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
doesn't match the first three bytes of the CEK, the KEK
invalid
2.3.4 Rationale for the Double
If many CEKs are encrypted in a standard way with the same KEK
the KEK has a 64-bit block size then after about 2^32
there is a high probability of a collision between different
of encrypted CEKs. If an opponent manages to obtain a CEK, they
be able to solve for other CEKs. The double-encryption
process, which makes every bit of ciphertext dependent on every
of the CEK, eliminates this collision problem (as well as
other potential problems such as bit-flipping attacks). Since the
is applied to the inner layer of encryption, even wrapping the
CEK with the same KEK will result in a completely different
key each time
An additional feature of the double wrapping is that it doesn'
require the use of any extra algorithms such as hash algorithms
addition to the wrapping algorithm itself, allowing it to
implemented in devices which only support one type of
algorithm. A typical example of such a device is a crypto token
as a smart card which often only supports a single block cipher and
single public-key algorithm, making it impossible to wrap keys if
use of an additional algorithm were required
3. Test
This section contains two sets of test vectors, a very basic set
DES which can be used to verify correctness and which uses
algorithm which is freely exportable from the US, and a stress-
version which uses very long passphrase and key sizes and a
of algorithms which can be used to verify the behaviour in
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
derivation stage and a full test of the key wrapping. Both tests
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
answer test the IV is set to all zeroes (equivalent to using ECB)
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 E
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 E
CEK formatting phase
length byte: 08
key check: 73 9D 83
CEK: 8C 62 7C 89 73 23 A2 F
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 6
first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D
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
: 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-
: (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
: EF E5 98 EF 21 B3 3D 6
: }
: }
68 04 16: OCTET
: 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 (
example one for AES or Blowfish) using a triple DES-CBC key
from the passphrase "All n-entities must communicate with
n-entities via n-1 entiteeheehees" with
{ 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 6
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 6
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
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 2
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 A
D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3
padding: FA 06 0A 45
complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66
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 4
first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71
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
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 D
EC 74 E6 CA D7 DB 26 0
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
: 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-
: (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
: BA F1 CA 79 31 21 3C 4
: }
: }
71 04 40: OCTET
: 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 D
: EC 74 E6 CA D7 DB 26 0
: }
4. Security
The security of this recipient information type rests on the
of the underlying mechanisms employed, for which further
can be found in RFC 2630 and PKCS5v2. More importantly, however
when used with a password the security of this information type
on the entropy of the user-selected password, which is
quite low. Pass phrases (as opposed to simple passwords)
STRONGLY RECOMMENDED, although it should be recognized that even
pass phrases it will be difficult to use this recipient
type to derive a KEK with sufficient entropy to properly protect
128-bit (or higher) CEK
Gutmann Standards Track [Page 11]
RFC 3211 Password-based Encryption for CMS December 2001
5. IANA
The PasswordRecipientInfo key encryption algorithms are identified
object identifiers (OIDs). OIDs were assigned from an
contributed to the S/MIME Working Group by the RSA Security.
additional encryption algorithms be introduced, the advocates
such algorithms are expected to assign the necessary OIDs from
own arcs. No action by the IANA is necessary for this document
any anticipated updates
The author would like to thank Jim Schaad, Phil Griffin, and
members of the S/MIME Working Group for their comments and
on this document
Author
Peter
University of
Private Bag 92019
Auckland, New
EMail: pgut001@cs.auckland.ac.
[ASN1] CCITT Recommendation X.208: Specification of
Syntax Notation One (ASN.1), 1988.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
1999.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based
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
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 ::=
FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1)
authenticationFramework(7) 3 }
CMSVersion,
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
-- it's specified in 1994/1997 ASN.1. Because of this it's
-- here from the source but rephrased as 1988 ASN.1.
-- details are given in [RFC 2898].
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL
prf
DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }
-- The PRF algorithm is also defined in PKCS5 and can neither
-- imported nor expressed in 1988 ASN.1, however it is encoded
-- 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
-- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it
-- likely that implementors will also encounter
-- interpretations of these parameters, usually using an
-- 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
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
[0] KeyDerivationAlgorithmIdentifier OPTIONAL
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifier ::=
KeyEncryptionAlgorithmIdentifier ::=
END -- PasswordRecipientInfo-88 --
Appendix B: ASN.1:1997
This appendix contains the same information as Appendix A in a
recent (and precise) ASN.1 notation, however Appendix A
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 ::=
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,
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
[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
AlgorithmIdentifier {{ PWRIAlgorithms }} },
...
}
-- Algorithm identifiers for algorithms used with
-- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is
-- MUST, all others are
PWRIAlgorithms ALGORITHM ::= {
{ OID des-ede3-cbc PARMS CBCParameter },
...
}
-- Supporting definitions. We could also pull in
-- AlgorithmIdentifier from an appropriately recent X.500 module (
-- wherever) but it's just as easy (and more convenient for readers
-- to provide a definition
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm})
}
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE
Gutmann Standards Track [Page 15]
RFC 3211 Password-based Encryption for CMS December 2001
&Type
}
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
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Gutmann Standards Track [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
