>>I am a bit confused by your message. You say that you want to add support
>>for "a PIN-protected smart card or something similar."
>>
>>First, this does not seem like an appropriate used of password-based key
>>management. The only password seems to be the local one used to gain
access
>>to the KEK stored on the smart card.
>
>In retrospect the term "PasswordRecipientInfo" used in the draft wasn't a
very
>good one, with the derivation info optional it's really more like a
>GeneralisedKEKRecipientInfo. At the time the best I could come up with was
>PW-RI.
I thought that the point was to add support for a CEK that was wrapped in a
KEK (in your example, one that was derived from a password). I think that
is what the draft says. So, if a shared secret is stored on a bunch of
tokens (e.g., smartcards), there out to be a way to carry something in the
parameters of the KeyDerivationAlgorithmIdentifier to allow the shared
secret and the public data to be combined to generate the KEK. One could
imagine a technique for combining the shared secret and the public value
similar to X9.42. And, if there is more than one shared secret (perhaps
for different recipient groups), then the protocol needs a way to identify
which one should be used.
You are right about the PIN, it does not impact the protocol. The PIN
controls access to the shared secret.
>>Second, if the KEK stored on the smart card has an identifier, then
>>KEKRecipientInfo should work as already defined.
>
>I'm not sure what the format is for the KEK on the card, but I suspect it's
>just a raw PIN-protected key (I imagine it's something like a PKCS #11
>secret key object, or more likely just a 16-byte linear file). In any case
>it won't work with KEKRecipientInfo because it's only defined for RC2 and
>3DES, you can't use it with IDEA unless you invent your own
>AlgorithmIdentifier.
As I stated above, if there is more than one shared secret (perhaps for
different recipient groups), then the protocol needs a way to identify
which one should be used.
Russ