On 2010/03/02 19:07, Vladimir Kotal wrote: > On 03/ 2/10 02:28 AM, Nikolay Elenkov wrote: >> On 2010/03/01 21:01, Vladimir Kotal wrote: >>> On 03/ 1/10 08:15 AM, Nikolay Elenkov wrote:: > > In Solaris Crypto Framework, supplying pInitArgs set to NULL_PTR to > C_Initialize() means to use internal locking primitives. > > See the following: > http://docs.sun.com/app/docs/doc/816-4863/chapter2-9d?a=view > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/pkcs11/libpkcs11/common/pkcs11General.c#C_Initialize
Indeed, I see. To me the spec is pretty clear about this, but apparently Solaris is interpreting it differently. This what the spec says (from the description of the C_Initialize function): (regarding the CK_C_INITIALIZE_ARGS) > If the flag isn?t set, and the function pointer fields aren?t supplied > (i.e., they all have the value NULL_PTR), that means that the application > won?t be accessing the Cryptoki library from multiple threads simultaneously. and then: > A call to C_Initialize with pInitArgs set to NULL_PTR is treated like a call > to > C_Initialize with pInitArgs pointing to a CK_C_INITIALIZE_ARGS which has the > CreateMutex, DestroyMutex, LockMutex, UnlockMutex, and pReserved fields set to > NULL_PTR, and has the flags field set to 0. I interpret this as NULL_PTR == I will not be using threads. >> >> Well, destroying the private key is hardly the way to prevent memory >> leaks. >> If, say, it were a smart card, with keys generated on the card, calling >> C_DestroyObject will the destroy the only copy of the key on the card. >> And that >> is not good... > > But for non-token objects it does matter very much :) The key-by-ref > project addresses this issue. I agree, put why destroy token objects (such as private/public keys)? Since pk11_destroy_rsa_key_objects does not exit on an error, I think with the Solaris PKCS#11 library it just returns an error (ignored), and that's why keys are not actually destroyed. The reason it (should) returns an error is that the session is read-only (C_OpenSession does not specify CKF_RW_SESSION). That is all theoretical since I haven't used the Solaris PKCS#11 library, though. In any case I still see no reason to call C_DestroyObject for token objects. As for session objects they should be destroyed automatically when the session is closed (from 6.4, Logical view of a token): > ?Session objects? are more > temporary: whenever a session is closed by any means, all session objects > created by that > session are automatically destroyed. In addition, session objects are only > visible to the > application which created them. I fail to see how key-by-ref addresses this. Key-by-ref just specifies the string you pass to OpenSSL and how to derive the actual slot/label from it. Once the key is loaded it's just a handle and calling C_DestroyObject on it will destroy the key. >> Yes, I've seen this. But keys are going to be generated by an external >> program >> and used from another program linked with OpenSSL. Neither of those >> know about >> key URI's, so we have to stick with 'simple' labels. > > AFAIK it works just fine with pktool(1) (or any other tool using PKCS#11 > API via libpkcs11.so to generate the key). The URI will have the key > label embedded in it so the C_Find*() ops will be able to find the key. I see. We might use it after all to get around the automatic slot selection thing. I will it give it a try. >> PK11_CMD_SLOT. I should have been more specifiy, command as in >> 'OpenSSL engine >> command', not executable. > > Can't see this one in the current version of the patch "released" by Jan > on his blog > (http://blogs.sun.com/janp/entry/pkcs_11_engine_patch_including). It > seems to be an artifact of the old PKCS#11 engine patch (which has > number of problems related to threads, BTW). However this does not match > with the README.pkcs11 reference above. What version of the patch are > you using exactly ? I am using the 0.9.8l one that comes with Bind 9.7.0. I just now realised that its been (heavily?) modified by ISC. It adds options to specify PIN in the config file, etc. I will to contact them about this. But if the key URI works OK though, I might not be needing this. > > and right below that it (v2.20rc3) says: > > It is defined as typedef CK_ULONG CK_SLOT_ID; > > and also: > > in particular, a system may have a slot identified by the value 0. > > So, I would tend to think that the "any value" is meant within the scope > of the type, in this case CK_ULONG which is at least 32-bit integer type > (chapter 5 of the spec). > Right, the things is 0 does not necessarily mean slot 0.
