From: Markus K. <ko...@rr...> - 2013-09-26 17:07:26
|
Hi, On 09/26/2013 06:48 PM, Douglas E. Engert wrote: > In Markus's code, you complained that the libp11 was using the > RSA_set_app_data and it was getting in the way of you using > the ex_data. But if you look closely, what libp11 is doing > is saving the pointer to the, PKCS11_KEY so the RSA sign, encrypt, > and decrypt functions can find the PKCS11_KEY. I was not really complaining, but ... lets say surprised, as app_data is a #define to ex_data with index 0 and ... registering the first ex_data hands you 0 as index, so initially my callback was free'ing p11 resources. I'd complain if my application, which is supposed to use app_data would clash with p11, but I do not have an application using app_data. > In the PKCS11_RSA_CRYPTO_EX structure in the engine which you > store using the RSA_set_ex_data, has a pointer to the same > PKCS11_KEY that the libp11 needs. > So a single ex_data index could be used if the code to keep > track of all of this was in the libp11. Yes, but in the engine loading the key happens, and everything related to the key is available. Which is why I put things there. In p11 you do not know which slots relate to which key. If you want tracking in p11, loading keys and certs (by slot/id, label) has to happen in p11, not in the engine. Traversing things backwards from the key to the slots won't work. The engine can call the p11 function, but p11 has to do the lifting. If you think that is an acceptable change, let me know. > The PKCS11_RSA_CRYPTO_EX is not particular to RSA. > and could also be used for ECDSA and any other key types > we add in the future. So a more generic name would be better. > (It still needs to be added to the RSA, ECDSA, or what ever > using the *_ex_data for that type of key.) Renaming to PKCS11_CRYPTO_EX is trivial. > (The ECDSA code I have working uses the ECDSA_set_ex_data > like the RSA_set_ex_data to store a pointer to the PKCS11_KEY. > Thus it would use the new version of the PKCS11_RSA_CRYPTO_EX. Markus |