More on KEKIdentifiers, and a suggested addition to CMS

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.