On 30.12.2008, at 21:28, Alon Bar-Lev wrote: > On 12/30/08, Martin Paljak <mar...@paljak.pri.ee> wrote: >> >>> The PKCS#11 specification does not limit concurrent application >>> access >>> to single token in any point in time. >>> The lock term was introduced by OpenSC due to implementation choice. >> At the same time, I see no line in the spec forbidding such >> implementation >> choices, which is a totally valid tunable together with pcsc >> options (for >> example, exclusive connect would result in almost similar behavior >> than >> pkcs11 locking). Which makes most sense to any given person, is a >> different >> story. > > Do you want to start standard fight? I don't understand... Why blindly > defend the current implementation... No. I'm not defending the current implementation nor want a standards fight, I would just like to know where exactly does it say that if a C_Login blocks access for other users, spec is not followed.
I'm all for better solutions for the users and I do agree that there are many ancient quirks in the current implementation. > Now... As you asked for standard quoting... > ... > %%%%%%%%%% Please read the following section carefully, I did not > copied all of it. > > 6.7.7 Example of use of sessions > We give here a detailed and lengthy example of how multiple > applications can make use > of sessions in a Cryptoki library. Despite the somewhat painful level > of detail, we highly > recommend reading through this example carefully to understand session > handles and > object handles. 6.7.7 talks mostly about sessions and how different session scenarios should be handled if there are multiple applications with multiple threads. I would like to quote the next paragraph: We caution that our example is decidedly not meant to indicate how multiple applications should use Cryptoki simultaneously; rather, it is meant to clarify what uses of Cryptoki’s sessions and objects and handles are permissible. In other words, instead of demonstrating good technique here, we demonstrate “pushing the envelope”. Threads or processes - all the same to some extent, at least when it comes to serializing access to some shared system resource, they look very much the same. If you take the description given for mutexes in 6.6.2 used for synchronizing different threads (which in a generic sense are similar to processes), which are allowed to block until the resource is freed, it seems perfectly valid for a whole application to lock access to some resource for as long as the implementation requires it: Mutex objects are simple objects which can be in either of two states at any given time: unlocked or locked. If a call is made by a thread to lock a mutex which is already locked, that thread blocks (waits) until the mutex is unlocked; then it locks it and the call returns. If more than one thread is blocking on a particular mutex, and that mutex becomes unlocked, then exactly one of those threads will get the lock on the mutex and return control to the caller (the other blocking threads will continue to block and wait for their turn). > %%%%%%%%%% Here you can see that two applications may sign, even one > application may delete the key at the same time the other application > sign using it... How can it be if both applications cannot > authenticate at the same time? I'm not justifying the current implementation nor want to say that multiple applications should not be supported, I just don't see in the v2.20 or 2.11 spec where it specifically forbids for an implementation from locking another application or thread from a shared resource if the implementation decides it wants to by blocking cryptoki calls until the resource is available again. Happy New Year! m. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
