Subject: KEKRecpientInfo KEKIdentifier

From: [email-masked] (Peter Gutmann)
Date: Mon, 25 Jan 1999 03:13:21 (NZDT)

The KEKIdentifier in the KEKRecipientInfo currently contains a mandatory OCTET 
STRING which is supposed to contain some magic key ID, however in what I guess 
would be the most common uses for KEK data encryption (either straight 
file/data encryption or "Included below are last weeks sales figures encrypted 
with the key we agreed on") there's no conceivable use for this value.  Could 
this be made optional like the other fields, or better yet could the whole 
KEKIdentifier be made optional (since it'll be empty without the OCTET 
STRING)?  Either:
 
    ...
    kekid [ 0 ] KEKIdentifier OPTIONAL,
    ...
 
(the preferred option) or alternatively:
 
KEKidentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING OPTIONAL,
    date GeneralizedTime OPTIONAL,
    other [ 0 ] OtherKeyAttribute OPTIONAL
    }
 
The former would be nicer since the latter will lead to odd-looking empty
SEQUENCEs appearing in most KEKRecipientInfo's.
 
A much uglier alternative is to use a zero-length OCTET STRING to denote "I
don't know what to do with this field", but that kind of defeats the point of
having it there in the first place since it's just a kludgy way of saying OCTET
STRING OPTIONAL.  My preferred solution for this would be KEKIdentifier
OPTIONAL since it reduces the amount of clutter.
 
Peter.

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Jan 1999 10:23:58 -0500

Peter:

I do not agree.

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.

Russ