Subject: Re: Suggested change to PasswordRecipientInfo

From: Russ Housley <[email-masked]>
Date: Thu, 02 Sep 1999 12:29:28 -0400

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

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 8 Sep 1999 01:17:03 (NZST)

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

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