Peter,
If you have multiple KEK keys which could be used to decrypt the file, then
you need to know which one to use. If there is only one possible KEK key
which could be used to decrypt the file, then I can see your point that the
KEKIdentifier would not be needed to identify which KEK to use. In summary,
I agree that the KEKIdentifier could be made optional.
- John
At 01:33 AM 2/5/99, pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz 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.