[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal: Supporting multiple callers in process
There are several issues related to having multiple callers of a PKCS#11 module in a process. I propose we either: a) Clarify these issues in the spec so that multiple callers can use a token within certain expectations. b) Define this as part of a profile where adhering callers are well behaved with regards to other callers in the same application. More details here: https://wiki.oasis-open.org/pkcs11/MultipleCallersPerProcess This is not meant to be an attempt at virtualizing PKCS#11 tokens or anything like that. In particular the login state of a token will always be per-process (what we currently call an application in PKCS#11). However with certain fixes (see the URL above) we can help multiple callers not tear out session from one another, or be needlessly blocked by one another. Some of these things may be possible within 2.40, and others may be longer term. Cheers, Stef 1. Counted Initialize/Finalize This is a longer term component, and may not be material for 2.40, pending discussion. Proposing that C_Initialize may be called multiple times within a process without returning CKR_CRYPTOKI_ALREADY_INITIALIZED. C_Finalize must be called the same number of times before actually finalizing the token. Corollary is that C_Initialize and C_Finalize implementations must be thread safe. 2. C_CloseAllSessions clarifications Clarify that C_CloseAllSessions should contain language which states that it should not be called gratuitously, since it will cause other (perhaps unrelated callers) of the token in the same process to fail. Callers of sessions should be aware that their sessions should be closed at any time, and should recover gracefully from this. 3. No assumptions about state after C_CloseSession and C_CloseAllSessions Callers should not make assumptions about the login state of a token after C_CloseSession or C_CloseAllSessions has been called, and be ready for either logged-in or logged-out state. Another caller may log in or have another session open which affects the login state. 4. CKU_SO + read only sessions Generic code which implements PKCS#11 enumeration (or related) patterns/algorithms, is complicated by the fact that they cannot rely on opening a read-only session. (eg: display or listing algorithms). These algorithms have to test the login state of the token in order to know whether they can open a read-only session, or whether the user is CKU_SO (in an inherently racy manner). We should remove the restriction of using read-only sessions together with CKU_SO.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]