[kmf-discuss] Re: [crypto-discuss] request comments for 2 enhancements

[Huie-Ying Lee]

Garrett D'Amore wrote:
> Huie-Ying Lee wrote:
>> Hi, all:
>>
>> This proposal is about resolving the following 2 enhancement requests:
>>    -RFE 4868006 (encrypt(1) and mac(1) needs to support token objects)
>>    -RFE 6517162 (pktool genkey needs to support generic secret key)
>>
>> My preliminary proposal has been reviewed by the KMF core team.  Below is
>> the updated design and I would appreciate any comments by next
>> Tuesday, Jan/30.
>>
>> Thanks,
>> Huie-Ying
> 
> 
> The most useful way to deal with secret symmetric keys is to allow them
> to be used with key wrapping facilities (e.g. import a session key
> wrapped with one's one public key -- needing the secured private key to
> get at it) or with key agreement algorithms like Diffie-Hellman. 
> 
> Unless your design supports one or the other of these, I don't see much
> value in secured (as in a hard token) symmetric keys.
> 
> Am I missing something?
> 
>     -- Garrett

Hi, Garrett:

Thank you for the comments.

If I understand your email correctly, what you sugggested is to provide key
wrapping facilities for a symmetric key to be used for key exchanging.  For example:
senerio:

   Party A
      1. Create a DES key
      2, Wrap it with party B's public key
      3. Sent the wrapped key to Party B

   Party B
      1. Receive the wrapped key from party A
      2. Unwrap it with party A's private key
      3. use the DES key to comunicate with party A

If my guess is correct, I think this is good suggestion and can be
addressed in a seperate enhancement.   And to support this new enhancement,
I think we also need to enhance "pktool" to support keypair generation which
is not supported directly for now.

The current Solaris encrypt(1), decrypt(1), and mac(1) commands
are simple, they just takes a keyfile or a passphrase, converts that to
a session key, then perform the crypto operations.   A user needs to
store the keyfile safely or remember the passphase that he/she uses for
each key.

The RFE 4868006 here is just to add the token object support to these 3 commands,
which allows a user to use a key that is already in a PKCS11 keystore.   If a user
uses many keys for various tasks, with the token object support, he/she only needs
to remember the pin to the keystore, instead of mantaining many keyfiles or
remembering many passphrases.

Thanks,
Huie-Ying