1

The PKCS #11 2.40 spec is a little ambiguous in its description of whether an object handle retrieved using session A can be used in session B to the same token.

The main spec states (all emphasis below is mine):

A particular object on a token does not necessarily have a handle which is fixed for the lifetime of the object; however, if a particular session can use a particular handle to access a particular object, then that session will continue to be able to use that handle to access that object as long as the session continues to exist, the object continues to exist, and the object continues to be accessible to the session.

While the usage guide states:

Object handles are similar to session handles in the sense that visibility of a given object through an object handle is the same among all threads of a given application.

and also...

Note that a Cryptoki implementation may or may not support separate spaces of handles for sessions and objects.

Finally, the usage guide includes a scenario, of which steps 16, 17 and 18 suggest you can use the same object handles. But the wording used is "the object associated with object handle 1", so it's not 100% clear that the handle was valid to use:

  1. A1 uses [A’s] session 4 to perform an object search operation to get a handle for O2. The search returns object handle 1....

  2. A1 attempts to use [A’s] session 4 to modify the object associated with [A’s] object handle 1. The attempt fails, because A’s session 4 is a R/O session, and is therefore incapable of modifying O2, which is a token object....

  3. A1 uses [A’s] session 7 to modify the object associated with [A’s] object handle 1. This time, since A’s session 7 is a R/W session, the attempt succeeds in modifying O2

Can anyone comment definitively on this topic? Or point to another part of the spec that unambiguously defines this?

1

Yes, object handles can be used across sessions.

Your first citation doesn't say anything about it. Its intention is to clarify that handles to the same (token) object can change between different invocations of an application, but as long as the application is running and a session exists it won't change.

The third citation clarifies that a handle casted to an int can appear both as session and object handle at the same time. Here in step 12, object handle 7 is returned but session handle 7 already exists. Kind of obvious.

Your second citation gets closer since the UG also says:

Different threads of an application should never share sessions

But your fourth citation should make it clear since in step 16 handle 1 is returned for object O2 in session 4, and in step 18 this handle 1 is used in session 7 and in fact object O2 is modified!

  • Across sessions of the same application only? – eckes Mar 15 at 2:55
  • Thanks for your response. Is this answer based on your reading of my citations (only), or do you have any practical or insider knowledge of PKCS #11 that contributes to this? I ask because if I get another answer from someone else that draws a different conclusion, it will be difficult to understand where the facts are coming from. – Duncan Jones Mar 15 at 6:16
  • @eckes: Yes. From the user guide's example step 13: "As with session handles, different applications have no access rights to each other’s object handles, and so B’s object handle 7 is entirely different from A’s object handle 7." – dannyM Mar 15 at 17:41
  • @DuncanJones: I'm developing a professional PKCS#11 provider. Nevertheless, the interpretation of your first two citations are mine. But the example in the UG doesn't leave room for interpretation IMHO. And in case someone else draws a different conclusion we could always ask the OASIS PKCS#11 committee. – dannyM Mar 15 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.