The idea is that the KEK is distributed out of band and cached by the
recipient(s). The KEKIdentifier is intended to be an index into the cache.
OK, this is one possible hypothetical situation in which a KEKIdentifier would
be useful. However (as has been pointed out in other debates on this list),
CMS is meant to be a Cryptographic Message Syntax, not (in this case) a
CachedpreviouslyagreedonKEK Message Syntax. Of the many ways in which it's
possible to use a KEK, the KEKIdentifier applies to only one very specific,
very special-case use. Requiring that this field be present for every
imaginable use and application of a KEK doesn't make any sense, because in
many applications there's absolutely no use for it.
As I mentioned in my previous message, the most common use for a KEK would be
for file encryption. I'm basing this claim on several years of reading
alt.security.pgp, in which almost the only use I've ever seen for PGP's -c
conventional encryption option (equivalent to the CMS KEKRecpientInfo) is for
file encryption. You've mentioned one theoretical possibility in which a
KEKIdentifier would be useful, but that isn't a reason to force its use in
every instance, especially when experience (it's use in PGP) shows that it'll
almost never be used in the way you've described. PGP has worked just fine
for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it
mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" and
you can let the users decide whether it really is essential or not - I'm not
asking that it be removed, simply that it be made optional so you can leave it
out where there's nothing to put in a KEKIdentifier.
(Minor nit: Since KEKRecipientInfo is still changing, could the version be
reset to 0 or 1 to go with the other CMS RecipientInfo types? There's no
real backwards compatibility problem because the format has changed in the
last few versions anyway, and it'll avoid having this odd artificially-high
version number for one particular RecipientInfo type).
Peter.