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

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 <rankney(_at_)erols(_dot_)com>
To: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz 
<pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz>; Russ Housley
<housley(_at_)spyrus(_dot_)com>
Cc: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>; 
burt(_at_)RSA(_dot_)COM <burt(_at_)RSA(_dot_)COM>
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 <housley(_at_)spyrus(_dot_)com>
> > To: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
> > Cc: ietf-smime(_at_)imc(_dot_)org; burt(_at_)RSA(_dot_)COM
> > 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.