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

[Russ Housley <[e-mail]>]

Peter:

I stayed silent to see if anyone would support your suggestion.  No one
spoke for it, but no one spke against it either.  I would like to heard
from the list members regarding this suggestion.  I do not consider silence
a reason to make an additional recipient type....

Russ

At 04:19 AM 2/21/99 +0000, Peter Gutmann wrote:
>I don't know what the final resolution on optional vs mandatory
KEKIdentifiers 
>was, but I note that PKCS #15, which AFAIK is the first non-S/MIME use of CMS 
>KEK encryption, already has to explicitly state that KEKIdentifiers are null 
>strings wherever they occur because they're not useful for anything (actually 
>there's a "not recommended" special-case use for them, see below).  I think 
>this proves my earlier point that there's going to be very little use for a 
>KEKIdentifier outside S/MIME, so that making it optional would be a good idea.
> 
>Looking at the way KEKRecipientInfo is being used in PKCS #15, there's a 
>rather obvious recipient type missing from CMS: Password-based encryption.  
>PKCS #15 has a hack for this which puts the key derivation information into 
>the KEKIdentifier (this being the special-case use mentioned above), but I'm 
>sure this isn't what it was intended for because it isn't a key identifier at 
>all but contains the AlgorithmIdentifier for the password processing.  What's 
>really needed is a new recipient type, PasswordRecipientInfo.  Included below 
>is a suggestion for this which could drop directly into the CMS draft.
> 
>Peter.
> 
>-- Snip --
> 
>6.2.4  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 ContentEncryptionAlgorithmIdentifier,
>        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 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 key-encryption key.
> 
>      encryptedKey is the result of encrypting the content-encryption key with
>      the password-derived key-encryption key.
> 
>   The key derivation algorithms are:
> 
>      KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
>        { IDENTIFIED BY id-PBKDF2 },
>        ...
>        }
> 
>    For key derivation, CMS implementations must include PBKDF2 [PKCS5v2].
>                        
>    For content (= key) encryption, 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.
> 
>-- Snip --
> 
>Comments:
> 
>The ContentEncryptionAlgorithmIdentifier is something like:
> 
>      ContentEncryptionAlgorithmIdentifier ::= {
>        { IDENTIFIED BY des-ede3-cbc },
>        { IDENTIFIED BY rc2CBC },
>        { IDENTIFIED BY cast5CBC },
>        { IDENTIFIED BY rc5CBC },
>        { IDENTIFIED BY ideaCBC },
>        { IDENTIFIED BY desCBC },
>        ... -- ... and anything else you can think of, eg Skipjack
>        }
> 
>but enumerating every possible one is superfluous as they're specified 
>elsewhere.
> 
>The content is encrypted is as per the KEK algorithm, but using the IV given 
>in the ContentEncryptionAlgorithmIdentifier instead of a fixed IV - this is 
>just standard CMS content encryption.  The advantage of using standard
OIDs is 
>that it doesn't require defining a completely new set of OIDs which parallel 
>all of the existing ones just to show that you're encrypting a key.  Another 
>way to handle this is as EncryptedContentInfo (which just adds an extra 
>SEQUENCE around the existing ContentEncryptionAlgorithmIdentifier + 
>EncryptedContent (=EncryptedKey)), but this is probably going overboard.
> 
>(I'm prepared to accept a 'kekid [0] KEKIdentifier OPTIONAL' after the
version 
> number if that's what's required to get people's grunt of approval for the 
> thing).
> 
>(Before people complain that you can't change the key wrap algorithm, if it 
> ever does become necessary to change it (and I thought the point of the 
> current key wrap design process was to build a solution once and for all), 
> all you need to do is increment the RecipientInfo version number and add 
> whatever you feel like).
> 
>Peter.
> 
>