OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[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 one
needs the functionality.

One example of a USB security token that do "not support generation of a key pairs" is the IronKey.
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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]