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

["John Ross" <[e-mail]>]

If you are going to allow the choice to be extended, I agree with Rick that
it should be controlled.  Just extending the choice with a new tag (and by
the way it also then needs a new version number), will give problems in the
future, as it is not a unique identifier.  What if a private extensions has
been defined already and used tag 3?  Also, if every extension to the choice
needs a new CMSversion number assigned, that may be a lot of CMSversion
around in the future. A while back I proposed to have an extensible "choice"
using octet string, it would be better using OID and any defined by as
follows:.


 The following is an example ASN.1:

 RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        kext [3] ExternalyDefinedKeyAgreement --for future or private key
management schemes }



ExternalyDefinedKeyAgreement :: = SEQUENCE {
    keyTypeIdentifier ObjectIdentier,
    keyTypeInfo OCTECT STRING --any defined by OID}

This will at lease make sure that there is unique identifiers for all the
extensions to recipient info.

Regards

John Ross

-----Original Message-----
From: Rich Ankney <[e-mail]>
To: [e-mail] <[e-mail]>; Russ Housley
<[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Wednesday, March 10, 1999 10:39 AM
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS


>If we're going to add another recipient type, I'd like to see it be an
>open type (OID and ANY DEFINED BY), of which this would be
>the first case.  ANSI X9F3 would like to add another recipient type,
>as well (the Tecsec CKM stuff from X9.69).  So we would have:
>
>Key transport
>KEK
>Key agreement
>Other
> Password-based
> CKM
>
>Regards,
>Rich
>
>----------
>> From: Russ Housley <[e-mail]>
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
>> Date: Monday, March 08, 1999 4:43 AM
>>
>> 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.
>> >
>> >