Proposal: Supporting multiple callers in process

[Stef Walter <stefw@redhat.com>]

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.