RFC 3211 (rfc3211) - Page 3 of 17


Password-based Encryption for CMS



Alternative Format: Original Text Document



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 [RFC 2630], 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 [RFC 2898] 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