ietf-smime
[Top] [All Lists]

Re: KEKRecpientInfo KEKIdentifier

1999-01-29 08:19:31
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.


<Prev in Thread] Current Thread [Next in Thread>