Peter:
In file encryption, you might want to put something here to clue the user
about which key. For example, "The key Fred and Johnny picked on New
Year's Day".
In the file encryption application, I would hope that more than on KEK
would be used. If you agree, then the syntax needs a way to identify which
one.
Remember this used to be called mail list keys....
Russ
At 04:21 AM 1/30/99 +0000, Peter Gutmann wrote:
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.