Re: [pkcs11] Proposal: Supporting multiple callers in process

[Stef Walter <stefw@redhat.com>]

On 21.04.2013 15:52, Gil Abel wrote:
> 
>> Anyone else have insight as the reasoning here why CKU_SO +
>> read-only
> sessions were originally disallowed?
> 
> 
> Yes, the reason is that if 'RO SO Functions' sessions would be
> allowed, they would have been identical in behavior to 'RO Public
> Session' sessions. Here is way. Let's assume we define those 2 types
> of sessions, the behavior would have been as follows:
> 
> - Session objects: RW access to session objects is always granted,
> regardless if the session is RO or RW (so we can forget about them
> for this discussions).
> 
> - Public Objects: both session types (assuming defined), would have
> allowed RO access to public objects.
> 
> - Private Objects: both session would NOT have allowed any type of
> access to private objects (which require the User's PIN).
> 
> So having a RO public session, and then logging on as SO to that
> session would have changed nothing, the same access would have
> remain, which makes this type of session meaningless....

Indeed, in theory it does.

But in practice this creates another whole set of awkward return values,
cases to check for and logic that must be maintained. As noted earlier
it prevents using standard logic (eg: find a certificate across all
tokens) with read-only sessions, without additional complexity.

Then there's the current inherent inability to use C_Login with CKU_SO
just because some other unrelated caller of the PKCS#11 is holding open
a read-only session on the token.

So in my opinion this should be simplified by either:

 * Having sessions opened read-only while SO logged in simply be
   CKS_RO_PUBLIC_SESSION.
 * C_Login CKU_SO would work regardless of the presence of other
   read-only sessions.
 * GetSessionInfo would return the CKS_RO_PUBLIC_SESSION state
   for read-only sessions regardless of whether logged in as SO
   or not-logged in (ie: public).
 * If the caller wishes to actually exercise the SO login to do
   SO things, then obviously they continue to need a read-write
   session.

or we could:

 * Defining CKS_RO_SO_FUNCTIONS in spite of it being meaningless.
 * C_Login CKU_SO would work regardless of the presence of other
   read-only sessions.
 * GetSessionInfo would return the CKS_RO_SO_FUNCTIONS state
   for read-only sessions when SO is logged in.
 * If the caller wishes to actually exercise the SO login to do
   SO things, then obviously they continue to need a read-write
   session.

I think the former is the more compatible approach.

In both cases, I believe that the practical benefit of complexity
reduction here outweighs the theoretical clarity of the model.

The following would be deprecated, along with their various explanations
and state info.

   CKR_SESSION_READ_ONLY_EXISTS
   CKR_SESSION_READ_WRITE_SO_EXISTS

Cheers,

Stef