[Top] [All Lists]

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

1999-03-11 10:50:24
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

 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.


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
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
Key agreement


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


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
a reason to make an additional recipient type....


At 04:19 AM 2/21/99 +0000, Peter Gutmann wrote:
I don't know what the final resolution on optional vs mandatory
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
strings wherever they occur because they're not useful for anything
there's a "not recommended" special-case use for them, see below).  I
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

Looking at the way KEKRecipientInfo is being used in PKCS #15, there's a

rather obvious recipient type missing from CMS: Password-based
PKCS #15 has a hack for this which puts the key derivation information
the KEKIdentifier (this being the special-case use mentioned above), but
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.
really needed is a new recipient type, PasswordRecipientInfo.  Included
is a suggestion for this which could drop directly into the CMS draft.


-- Snip --

6.2.4  PasswordRecipientInfo Type

  Recipient information using a user-supplied password is represented
in the
  type PasswordRecipientInfo.  Each instance of PasswordRecipientInfo
  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
     user-supplied password.

     keyEncryptionAlgorithm identifies the content-encryption
algorithm, and
     any associated parameters, used to encrypt the content-encryption
     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

   For content (= key) encryption, CMS implementations must include
   in CBC mode, should include RC2 in CBC mode, and may include other
   algorithms (CAST-128, RC5, IDEA, Skipjack) and modes as required.
   implementations should not include any KSG ciphers such as RC4.

-- Snip --


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

The content is encrypted is as per the KEK algorithm, but using the IV
in the ContentEncryptionAlgorithmIdentifier instead of a fixed IV - this
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
all of the existing ones just to show that you're encrypting a key.
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
number if that's what's required to get people's grunt of approval for

(Before people complain that you can't change the key wrap algorithm, if
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 you need to do is increment the RecipientInfo version number and
whatever you feel like).