On 12/30/08, Martin Paljak <[email protected]> wrote:
> On 29.12.2008, at 20:48, Alon Bar-Lev wrote:
> > On 12/29/08, Martin Paljak <[email protected]> wrote:
> > > On 27.12.2008, at 22:18, Alon Bar-Lev wrote:
> > > > Until we do so, the PKCS#11 provider is *NOT* compliant with the
>> > > specification.
> > > Please elaborate?
> > 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... Whatever you think there are few
facts to follow:
FACT A - All other PKCS#11 providers allow sharing the token between
processes at any point in time.
FACT B - All (at last popular) PKCS#11 aware applications are
implemented under the assumption PKCS#11 provider enables sharing.
FACT C - (As you mentioned about MS PC/SC) All Microsoft CSP
implementations allow sharing the token between processes at any point
in time.
FACT D - (If we already discussed CSP) All Microsoft CSP aware
applications are implemented under the assumption CSP enables sharing.
FACT E - OpenSC PKCS#11 provider is the only provider (I know of, and
I know many) that has this limitation.
FACT F - Users that use OpenSC PKCS#11 provider cannot use it with the
most popular applications.
I think that FACT F alone is enough to understand that we do not
provide a great service to our users. Even if you don't agree that
implementation of application is correct, you should provide a
solution to users.
Now... As you asked for standard quoting...
%%%%%%%%%% No return code out of C_Login for failure due to already
authenticated session on other process.
C_Login Return values: CKR_ARGUMENTS_BAD, CKR_CRYPTOKI_NOT_INITIALIZED,
CKR_DEVICE_ERROR, CKR_DEVICE_MEMORY, CKR_DEVICE_REMOVED,
CKR_FUNCTION_CANCELED, CKR_FUNCTION_FAILED,
CKR_GENERAL_ERROR, CKR_HOST_MEMORY, CKR_OK,
CKR_OPERATION_NOT_INITIALIZED, CKR_PIN_INCORRECT,
CKR_PIN_LOCKED, CKR_SESSION_CLOSED,
CKR_SESSION_HANDLE_INVALID, CKR_SESSION_READ_ONLY_EXISTS,
CKR_USER_ALREADY_LOGGED_IN,
CKR_USER_ANOTHER_ALREADY_LOGGED_IN,
CKR_USER_PIN_NOT_INITIALIZED, CKR_USER_TOO_MANY_TYPES,
CKR_USER_TYPE_INVALID.
%%%%%%%%%% 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.
%%%%%%%%%% As you can see, application should not be aware of other
applications doing anything with the token.
11.6 Session management functions
A typical application might perform the following series of steps to
make use of a token
(note that there are other reasonable sequences of events that an
application might
perform):
1. Select a token.
2. Make one or more calls to C_OpenSession to obtain one or more
sessions with the
token.
3. Call C_Login to log the user into the token. Since all sessions an
application has
with a token have a shared login state, C_Login only needs to be
called for one of the
sessions.
4. Perform cryptographic operations using the sessions with the token.
5. Call C_CloseSession once for each session that the application has
with the token, or
call C_CloseAllSessions to close all the application's sessions
simultaneously.
As has been observed, an application may have concurrent sessions with
more than one
token. It is also possible for a token to have concurrent sessions
with more than one
application.
%%%%%%%%%% 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?
13.2 Multiple Application Access Behavior
When multiple applications, or multiple threads within an application,
are accessing a set
of common objects the issue of object protection becomes important.
This is especially
the case when application A activates an operation using object O, and
application B
attempts to delete O before application A has finished the operation.
Unfortunately,
variation in device capabilities makes an absolute behavior
specification impractical.
General guidelines are presented here for object protection behavior.
Whenever possible, deleting an object in one application should not
cause that object to
become unavailable to another application or thread that is using the
object in an active
operation until that operation is complete. For instance, application
A has begun a
signature operation with private key P and application B attempts to
delete P while the
signature is in progress. In this case, one of two things should
happen. The object is
deleted from the device but the operation is allow to complete because
the operation uses
a temporary copy of the object, or the delete operation blocks until
the signature
operation has completed. If neither of these actions can be supported by an
implementation, then the error code CKR_OBJECT_HANDLE_INVALID may be
returned to application A to indicate that the key being used to
perform its active
operation has been deleted.
Whenever possible, changing the value of an object attribute should
impact the behavior
of active operations in other applications or threads. If this can not
be supported by an
implementation, then the appropriate error code indicating the reason
for the failure
should be returned to the application with the active operation.
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
