You can use your custom PKCS11 config and as long as you call the
KeyStore API to store the key (generated as session key) under the
desired alias, it will be saved as a token key as a result.
Have you tried it and see if this solves your problem?
Valerie
On 04/19/10 08:08, Tomas Gustavsson
Hi David,
I think you've done a good job of convincing me!
The key idea is that updaters should mimic the access permissions
of regular field updates by callers. Since those are not affected by
what's further up the stack, neither should the field updaters.
So I'm promoting myself from "messeng
If we need it it's usually for all keys, both RSA and EC.
Cheers,
Tomas
"Michael StJohns" wrote:
>At 04:34 AM 4/19/2010, Tomas Gustavsson wrote:
>
>>Hi,
>>Sorry being late, I was away on vacation.
>>
>>Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we
>>specify toke
At 04:34 AM 4/19/2010, Tomas Gustavsson wrote:
>Hi,
>Sorry being late, I was away on vacation.
>
>Yes in most cases we do use a custom PKCS11 config fil, with token=yes. If we
>specify token=false would it still be a token object on the HSM finally?
Yes. The C_CopyObject turns the Session objec
Hi,
Sorry being late, I was away on vacation.
Yes in most cases we do use a custom PKCS11 config fil, with token=yes.
If we specify token=false would it still be a token object on the HSM
finally?
For most HSMs we need to use a cusom PCKS11 config file, otherwise it is
not possible to gener
