Re: More on KEKIdentifiers, and a suggested addition to CMS

[Magnus Nystrom <[e-mail]>]

As an alternative, if the current CMS draft would allow for the 'PBES2'
algorithm identifier defined in PKCS #5 v2 in the set of
KeyEncryptionAlgorithms, there would be no need for changing the ASN.1 in
CMS. Another advantage with this is that it would enable an easy way to
send encrypted email where the key is derived from a previously
agreed-upon password.

I realize that this may require PKCS #5 v2 to be published as an
informational RFC.

-- Magnus

Magnus Nyström            Email: [e-mail]
RSA Laboratories          Phone: [phone]

On Thu, 11 Mar 1999, Peter Gutmann wrote:

> I think the way to avoid the "too late for CMS" problem is to publish
> PasswordRecipientInfo as its own draft which can follow on to CMS at a
> later date.  To handle this all you need to do is add a '...' at the 
> end of the RecipientInfo types in CMS (I think the '...' is implied 
> anyway, since presumably there'll be more than three different types 
> defined at some point).  I submitted a proposed draft covering this a 
> few days ago, I guess I'll jump the gun a bit and post it here (it's 
> fairly short) to give people a better idea of what it could look like.
> 
> Peter
> 
> -- Snip --
> 
> Internet Draft                                      Editor: Peter Gutmann
> draft-ietf-smime-password-00.txt                    University of Auckland
> February 26, 1999
> Expires in six months
> 
>                     Password-based Encryption for S/MIME
> 
> 1. Introduction
> 
> This document describes a password-based content encryption mechanism for
> S/MIME.  This is implemented as a new RecipientInfo type and is an extension to
> the RecipientInfo types currently defined in CMS [CMS].
> 
> The format of the messages are described in ASN.1:1994 [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 [RFC2119].
> 
> This draft is being discussed on the 'ietf-smime' mailing list.  To
> subscribe, send a message to:
>      [e-mail]
> with the single word
>      subscribe
> in the body of the message. There is a Web site for the mailing list at
> <http://www.imc.org/ietf-smime/>.
> 
> 1.1 Password-based Content Encryption
> 
> CMS currently defineds 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.
> 
> 1.2.1  PasswordRecipientInfo Type
> 
> Recipient information using a user-supplied password is represented in the type
> PasswordRecipientInfo.  Each instance of PasswordRecipientInfo will transfer
> the content-encryption key to one or more recipients who have the previously
> agreed-upon password.
> 
>     PasswordRecipientInfo ::= SEQUENCE {
>       version CMSVersion,  -- always set to 0
>       keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>       encryptedKey EncryptedKey }
> 
> The fields of type PasswordRecipientInfo have the following meanings:
> 
>   version is the syntax version number.  It shall always be 0.
> 
>   keyDerivationAlgorithm identifies the key-derivation algorithm, and any
>   associated parameters, used to derive the key-encryption key (KEK) from the
>   user-supplied password.
> 
>   keyEncryptionAlgorithm identifies the content-encryption algorithm, and any
>   associated parameters, used to encrypt the content-encryption key with the
>   password-derived KEK.
> 
>   encryptedKey is the result of encrypting the content-encryption key with the
>   password-derived KEK.
> 
> 1.2.2 Rationale
> 
> Password-based key wrapping is a two-stage process, a first stage in which the
> user-supplied password is converted into a KEK, and a second stage in which the
> KEK is used to encrypt a content-encryption key.  These two stages are
> identified by the two algorithm identifiers.  Although the PKCS #5 standard
> wraps these up into a single AlgorithmIdentifier, this design is particular to
> that standard and may not be applicable for other password-based key wrapping
> standards.  For this reason the two steps are specified separately.
> 
> 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 ALGORITHM-IDENTIFIER ::= {
>       { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
>       ...
>       }
> 
> CMS implementations must include PBKDF2 [PKCS5v2].
> 
> 2.2 Key Encryption Algorithms
> 
> These algorithms are used to encrypt the content (the key) using the derived
> KEK.  The content encryption algorithms are:
> 
>     KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs
> 
> CMS implementations must include Triple-DES in CBC mode, should include RC2 in
> CBC mode, and may include other algorithms (CAST-128, RC5, IDEA, Skipjack) and
> modes as required.  CMS implementations should not include any KSG ciphers such
> as RC4.
> 
> 2.3 Symmetric Key Encryption Algorithms
> 
> <<Align with CMS KEK algorithm when it's stable.  The content is encrypted is
>   as per the KEK algorithm, but using the IV given in the
>   KeyEncryptionAlgorithmIdentifier instead of a fixed IV - this is just
>   standard CMS content encryption.  The latest CMS KEK stuff looked like it was
>   moving in this direction anyway>>
> 
> 3. 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
> CMS and PKCS5v2.
> 
> Appendix A: ASN.1 Module
> 
> PasswordRecipientInfo
>     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
>       modules(0) pwri(n+1) }
> 
> DEFINITIONS IMPLICIT TAGS ::=
> BEGIN
> 
> IMPORTS
> 
>   FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) }
>        PBKDF2-params, PBES2-Encs;
> 
> PasswordRecipientInfo ::= SEQUENCE {
>   version CMSVersion,  -- always set to 0
>   keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>   keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>   encryptedKey EncryptedKey }
> 
> KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
>   { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
>   ...
>   }
> 
> KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs
> 
> END
> 
> References
> 
>   ASN1  Recommendation X.680: Specification of Abstract Syntax Notation One
>         (ASN.1), 1994.
> 
>   CMS   Cryptographic Message Syntax, draft-ietf-smime-cms-10.txt, Russ
>         Housley, December 1998.
> 
>   PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, Third Draft, RSA
>         Laboratories, February 1999.
>         <<Presumably this will become an RFC as soon as it's finalised, include
>           this as the actual reference>>
> 
>   RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, S.Bradner,
>         March 1997.
> 
>