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.
Uhh, I don't understand this comment - there's no public value/data being
conveyed. What you're conveying is KEK( CEK ) and (optionally) the
information required to turn a password into a KEK. If by "public value" you
mean the salt, then it's already being handled as part of the password->KEK
process specified in PKCS #5 v2.
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.
I can see your point, but I guess if there's any significant demand for it it
can be added later (ie in version n+1 add some sort of xxxID OPTIONAL field).
The reason I'm reluctant to add it at this point is that it's not at all clear
what form the ID should have (I'd really prefer to avoid the traditional
OCTET STRING hole) and/or if there's a great need for it. The main use for
PWRI at the moment is for encrypting files (key files, stored email, whatever)
for which there's only one "recipient" (ie the file owner, although calling
that a recipient is probably stretching the term a bit. I should probably add
a comment on this to the draft).
Peter.