[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO
On 05/30/13 03:13 PM, Andrey Jivsov wrote:
The ability to supply CKA_PUBLIC_KEY_INFO for C_CreateObject (and C_UnwrapKey) was more suspenders and belt to deal with the case where the token may not support generation of a key pair, but supports import of the private key. I don't know of any tokens like this, but I wouldn't be surprised to find them. I'm happy to remove it if it no oneneeds the functionality.
One example of a USB security token that do "not support generation of a key pairs" is the IronKey.
http://www.ironkey.com/en-US/It only allows generation of key pairs during manufacturing state (or, provisioning state).
A few key pairs were pre-generated for end-users at the manufacturer.However, it becomes a pain for the end-users since the user may not perform a certificate signing request for the second time with the CA (it was Cisco CA). The CA would accept the first time request, but it would assume the key pairs has been compromised when it sees the request (certificate signing request) for the second time with the same key pairs. But, anyway, off topic. Any USB security tokens or HSMs should allow user to generate, and re-generate new keys after manufacturing state.
-- Best, Oscar