Subject: Re: Suggested change to PasswordRecipientInfo

From: Russ Housley <[email-masked]>
Date: Wed, 04 Aug 1999 14:41:45 -0400

Peter:

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.

Second, if the KEK stored on the smart card has an identifier, then 
KEKRecipientInfo should work as already defined.

Russ

At 09:25 AM 7/23/99 +0000, Peter Gutmann wrote:
>Currently PasswordRecipientInfo assumes you'll be feeding in something
>(referred to in the text as a password, although this is a somewhat misleading
>name since it's really "any keying material") and transforms it into a KEK
>which it uses to wrap a content-encryption key (CEK), in the same way that
>KeyTransRecipientInfo uses a public key to wrap the CEK, etc etc.  The process
>is:
>
>     password -> KEK -> CEK
>
>with the steps "password -> KEK" and "KEK -> CEK" being identified by
>AlgorithmIdentifiers.  Currently "password -> KEK" uses the PKCS #5v2 ID, and
>"KEK -> CEK" uses any standard encryption algorithm ID (DES, 3DES, IDEA, CAST,
>RC2, etc etc).
>
>Someone recently asked how you'd use this when there was no password available
>(ie how to avoid the "password -> KEK" step), in their case they wanted to use
>an IDEA key on a crypto token (I'm guessing this was referring to a
>PIN-protected smart card or something similar).  There are two ways to handle
>this, either use a null ID for the "password -> KEK" ID, or make the use of
>this field optional, ie change:
>
>     PasswordRecipientInfo ::= SEQUENCE {
>       version CMSVersion,   -- Always set to 0
>       keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>       encryptedKey EncryptedKey }
>
>to:
>
>     PasswordRecipientInfo ::= SEQUENCE {
>       version CMSVersion,   -- Always set to 0
>       keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
>       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>       encryptedKey EncryptedKey }
>
>with a corresponding change in the text to say that if the key derivation
>information is absent then it's assumed the KEK is supplied from an external
>source (in this case the crypto token).  This seems like a nice logical way to
>handle it (if the derivation info is present, ask for a password and 
>convert it
>to a KEK, otherwise get the KEK via some other means), and is more sensible
>than the use of a null ID to denote the absence of a password (using a special
>value to denote that no special value should be used seems silly).
>
>Comments?
>
>Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 5 Aug 1999 09:12:10 +1200 (NZST)

Russ Housley <[email-masked]>

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

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

Peter.