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
At 01:33 AM 2/5/99 +0000, Peter Gutmann wrote:
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.