Subject: Re: KEKRecpientInfo KEKIdentifier

From: [email-masked] (Peter Gutmann)
Date: Fri, 5 Feb 1999 01:33:38 (NZDT)

>I believe that the KEKRecpientInfo KEKIdentifier should not be optional. The
>recipient always needs to have a means of identifying which KEK to use to
>process the received message.
 
Well, that's a good point, and if you were right I'd agree with you.  You're 
assuming that the only thing CMS will ever be used for throughout its entire 
existence is handling S/MIME messages ("process the received message").  As I 
pointed out a few days ago, KEKIdentifier has no known (non-contrived) use for 
things like file encryption, which 8 years of experience with PGP indicate 
would be the most common use for KEKRecipientInfo.  As John Ross suggested, if 
it's needed for S/MIME then mandate it in MSG or ESS, but don't force anyone 
who uses CMS into using it just because S/MIME happens to need it.
 
Peter.

---

From: Russ Housley <[email-masked]>
Date: Thu, 04 Feb 1999 12:36:29 -0500

Peter:

Excuse my hasty word choice.  Let me try again.

I believe that the KEKRecpientInfo KEKIdentifier should not be optional.
The decryptor always needs to have a means of identifying which KEK was
used by the encryptor, even if the encryptor and decryptor are the same party.

If CMS is being used to support a file encryption application, I would
expect more that one file-encryption key to be used.  However, one could
imagine a case where files that are not intended to be shared would wrap
those file-encryption keys in the same key-encryption key (KEK).  But,
wait.  There are probably also files that will be shared.  These need a
different KEK.  So, some plaintext data is neede to distinguish these KEKs.
 I suggest that the KEKRecpientInfo KEKIdentifier is a good choice.

If the file encryption application does not support more than one KEK (for
example, no files are shared), then I still see a use for the
KEKRecpientInfo KEKIdentifier.  Two people using this application should
get a reasonable error if they try to dercypt each other's files.  In this
case, the KEKRecpientInfo KEKIdentifier could be the user name or the
application serial number.

Russ