ietf-smime
[Top] [All Lists]

Re: Suggested change to PasswordRecipientInfo

1999-08-04 13:37:17
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.


<Prev in Thread] Current Thread [Next in Thread>