OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [pkcs11] Proposal: Supporting multiple callers in process


> 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....

Gil. 




-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Stef Walter
Sent: Thursday, April 18, 2013 6:11 PM
To: Darren J Moffat
Cc: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Proposal: Supporting multiple callers in process

On 16.04.2013 16:23, Darren J Moffat wrote:
> 
> 
> On 04/15/13 14:00, Stef Walter wrote:
>> There are several issues related to having multiple callers of a PKCS#11
>> module in a process. I propose we either:
> 
> There is also a semi-related set of issues to do with what happens on
> fork() that we should also discuss - the fork saftey issues have caused
> us more problems on the Solaris/Java boundary than thread safety issues.

Yes, that's certainly a rough area. Do you have any proposals here?
Reconciling threads/fork seems extremely hard to get right in a general
sense. Is there something specific PKCS#11 can do to make this easier?

... besides a test suite... :)

>>   a) Clarify these issues in the spec so that multiple callers can use
>>      a token within certain expectations.
> 
> I'd rather we do this and where necessary update the spec to allow
> things as you have detailed below.

Does making C_Initialize and C_Finalize thread safe seems to require
mutexes that are initialized either statically or on module load.
Obviously the major platforms have no problem with that, but is this
something we can require of everyone?

Trying to get a sense here if there would be implementation issues.

>> Proposing that C_Initialize may be called multiple times within a
>> process without returning CKR_CRYPTOKI_ALREADY_INITIALIZED.
> 
> In the Solaris provided libraries and applications that call
> C_Initalize() we check for CKR_OK and CKR_CRYPTOKI_ALREADY_INITIALIZED
> and treat both as success.

Do you wrap C_Initialize somehow to make it thread safe? We do in
p11-kit as a work around for the current deficiencies.

>> 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.
> 
> We actually had that implemented for our Solaris libpkcs11 many years
> ago, but we removed it before we integrated into Solaris 10 and shipped.
>  The reason we removed it is that it wasn't compliant with the spec.
> 
> I'd like to see this formalised as being the correct thing to do.

Yes. This would require module implementations to maintain the
initialization count. Not that big a deal, but we need to decide if this
is 2.40 material.

>> 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.
> 
> Agreed.
> 
>> 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.
> 
> Agreed.
> 
> 
>> 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.
> 
> That makes sense to me.

Anyone else have insight as the reasoning here why CKU_SO + read-only
sessions were originally disallowed?

Cheers,

Stef


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]