hi Julien, thanks for your reply.
Julien Pierre wrote: > At this time softoken is still tied to NSS. It requires an > initialization string to be passed to C_Initialize. If you can make your > other applicaitons pass that string, you might be able to use it. What is the syntax of that initialization string? I couldnt find any docs regarding a init string for C_Initialize. I guess this has something to do with telling softoken where the "key.db" and "cert.db" is located? Is this C_Initalize thing the only change which made softoken not fully PKCS#11 compatible? Are there any other things which make softoken not fully PKCS#11 compatible? > softoken was written separately and isn't based on ckfw. Since it > implements nearly all functions in the specification, making softoken > use CKFW wouldn't make sense. Ok. But why does softoken and builtin module only export the C_GetFunctionList function? I thought softoken and builtin are "real" PKCS#11 Modules. Why don't they export functions like C_Initialize, and all the other PKCS#11 functions directly? Instead softoken exports C_GetFunctionList, NSC_GetFunctionList, FC_GetFunctionList. What is the difference between these 3 functions? My goal is to modify the softoken in terms of its private key handling. Thats because i have a device which stores the private key securely and it performs some private key crypto operations. I want to make the secure device available through pkcs#11. So i thought of modifing the softoken , keeping all public key and public crypto operations and modify all private key operations and storage calls to my secure device. So i dont have to spend much time to implement crypto operations like encrypt or verify, certstorage which can easily be done by the softoken. Is this a reasonable approach or am i totally wrong? best regards Christoph Brueckner
