Subject: Re: KEKRecpientInfo KEKIdentifier

From: [email-masked] (Peter Gutmann)
Date: Sat, 30 Jan 1999 04:21:54 (NZDT)

>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.

---

From: EKR <[email-masked]>
Date: 29 Jan 1999 08:58:24 -0800

> out where there's nothing to put in a KEKIdentifier.
I've got to go with Peter here. While I think that for messaging,
the index is more useful, I don't see any harm in making it optional.
We can always make MSG require it.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 Jan 1999 17:17:05 -0500

What do others think?

I am unwilling to make it optional without a change to MSG that mandates it
for S/MIME.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 Jan 1999 17:15:51 -0500

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