RE: [pkcs11] RE: Async Operations

Hi Darren,

CKF_ASYNC_SESSION_SUPPORTEDâperhaps. Itâs not Âinconsistent with other functionality in the spec that applications attempt to use and get surprised by (RSA OAEP, RSA PSS, ECC curves supported, etc.). Itâs also not really possible for us to provide flags for the case where some functions (say C_GenerateKeyPair) can have its state saved across invocations, but others (say C_SignFinal) cannot. For that matter, we donât differentiate between functions that can or cannot support async in any fashion. Basically, we can tell the caller that:

You can open an async session
You might get CKR_PENDING as a response; you should handle it
You might be able to persist an operation across invocations

I donât know that we can tell them much more than that. Iâm not opposed to adding a second flag to tell them 3, but I donât know that itâs adding much. As an application, I have to try it to see if it works regardless.

Apparently the existing Notify/callback feature is very specific to some operation (I canât recall which) and we were opposed to reusing it for this. My personal take on âpollingâ vs ânotificationsâ is that I can turn a polling API into a notification API using a thread, but I canât turn a notification API into a polling API. However, the way C_AsyncComplete is designed can work with a notification scheme if we want to add one.

Init and Update are pretty much the same. Just loop over successive calls until it returns something other than CKR_PENDING. Iâll update the example to show that.

Sincerely,

Jonathan

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of JOHNSON Darren
Sent: Friday, February 17, 2023 5:41 AM
To: pkcs11@lists.oasis-open.org
Subject: [EXT][pkcs11] RE: Async Operations - comments

THIS MESSAGE COMES FROM AN EXTERNAL SOURCE. PLEASE VERIFY THE CONTENTS OF THIS MESSAGE BEFORE PROCEEDING.

Hi,

three more questions on this proposal.

CKF_ASYNC_SESSION_SUPPORTED is to be documented for slot, token and session.

But this flag is being grossly overloaded I think. It is used to indicate support for async operations within a session. But it also is used to indicate support for the ability to get and ID and later join an operation.

Asynchronous operations with in a session is one thing and will probably be commonly supported.

But the ability detach and later join an operation with a session (especially if we allow reboots/restarts of an application) is a very different type of functionality and may not be as commonly supported.

Applications may query CKF_ASYNC_SESSION_SUPPORTED and try to use one type of functionality or the other, but find the vendor may not support all of it.

So I think there should be two separate flags to identify these two types of functionality.

Thoughts?

This second question Iâll ask. But Iâm sure it was discussed so an answer will probably be readily available.

As it is defined, asynchronous operations require polling which has many pros/cons.

Was any thoughts given to using the Notify/callback feature to allow vendors to notify applications when an asynchronous operation is complete?

Or a more specific callback/notification feature?

Third question.

The examples all show asynchronous handling for the Update and Final operations. But not for the Init operation. Is this intentional?

When we consider setup, key expansion, generation of ephemeral key material, possibly generation of trees/etc, in theory an Init operation could take longer as well. We donât strictly dictate the separation between operation initialization vs an operation update/final.

So am I correct to assume that Init can also be processed asynchronously? and if so, the example, or at least the text, should explain that.

Thanks

Darren

From: JOHNSON Darren
Sent: Wednesday, February 15, 2023 10:35 AM
To: 'pkcs11@lists.oasis-open.org' <pkcs11@lists.oasis-open.org>
Subject: Async Operations - comments

I missed all the discussions around this proposal. So I apologize if Iâm asking questions that were already discussed and resolved.

in section 4.b, it states âIf the token does not support asynchronous operations, it should return CKR_SESSION_ASYNC_NOT_SUPPORTED. Tokens must support synchronous sessions. Tokens may support asynchronous sessions and may return CKR_PENDING if the token determines that the operation will take a long time to conclude.â .

I assume the first part, âTokens must support synchronous sessionsâ is going to be removed? Tokens may support async sessions.

In CK_ASYNC_DATA, the field ulValue is defined as CK_ULONG. But shouldnât it be CK_ULONG_PTR and pulValueLen as this is going to receive the data and is expected to follow the conventions for all functions returning data?

In CK_ASYNC_DATA, pValue is defined as âon completion contains a pointer to the original input buffer, caller is responsible for freeing this memoryâ.

Is this supposed to say âoriginal input bufferâ? Or should it be âoriginal output bufferâ?

Whether the operation is âon completionâ or âstill processingâ, this value should always âpoints to the location that receives the resultâ. The state of the operation is unknown to the caller, and should not have an impact on the value of âpValueâ, Right?

On completion, the result is copied there.

Do we really require that it is the âsameâ buffer? Does that imply that we are assuming/expecting or just allowing providers to make use of that buffer during the operation? Which may make sense for memory constrained environments. and may also make sense if a token is streaming result data out and filling this buffer as it progresses.

Or should we be more strict and not have this requirement for the âsameâ buffer, which means the provider should not use any of the applications memory. This would be problematic in many cases I think

Regardless, we should clearly state who is the owner of that buffer while the operation is being processed asynchronously.

âIfâ it must be the same buffer, should we really require it to be re-provided? Should we require any of the output pointers to be re-provided? What is the reason for them to be re-provided?

In the summary/introduction, it states âreestablish the application/module connection with respect to the asynchronous operationâ. To be clear, this feature is only covering the case where a session is closed, and the operation is joined/connected to a different session; be it a newly opened session or an existing session. All of this is within the context of single successful calls to C_Initailize->C_Finalize . There is no expectation for this to span successful calls to C_Finalize->C_Initalize, right?

Looking back at the meeting minutes, I see that this update to the proposal is supposed to cover a reboot. Is that true? So an application can be restarted, and attempt to join the operation?

Was there any discussion around authentication requirements? About which role/user initiated the operation vs what role/user is joining the operation? I would assume that only the same role (and user if a user was authenticated) could resume the operation. Or is the âIDâ value essentially treated like an authorization token and grants rights for any role/user to join the operation? Whatever the answer is, it should be documented.

What about the current roleâs/userâs ability to access and use the key that is currently being used for the operation. Without requiring the same role/user that was used to initiate the operation, we get in to discussions around escalation.

C_AsyncGetID description use âpResultâ instead of âpulIDâ.

C_AsyncGetID. Maybe this is just a providerâs problem to deal with and may feed in to their decision to allow this call to succeed or not. Related to the questions about the result buffer, the wording above suggests that a provider would be able to use the result buffer when handling asynchronous operationsâ because the call to C_AsyncComplete must pass in the same pointer. So then after a successful call to C_AsyncGetID , the original memory pointed to by the result point (be it form the original call, or any following calls to C_AsyncComplete) must no longer be referenced by the provider.

This may not be obvious to all readers and should probably be mentioned.

C_AsyncJoin; the field ulValue is defined as CK_ULONG. But shouldnât it be CK_ULONG_PTR and pulValueLen as this is going to receive the data and is expected to follow the conventions for all functions returning data? Also, if no output is returned, isnât it better to set the pulDataLen value to 0?

This question may be ignored as it may be addressed by the next question below.

Why should C_AsyncJoin need to provide pData and ulData? From what I understand, the application will need to call C_AsyncComplete, right? so the output buffer will be provided via CK_ASYNC_DATA? Requiring pData and ulData during the C_AsyncJoin would only be necessary if we think the provider will need to make use of that memory while processing the operation. But the operation has gone through a C_AsyncGetID, so it must already have decoupled itself from any application memory space and is presumably still processing

Shouldnât C_AsyncJoin pass CKA_ASYNC_DATA as a parameter so that all of the output locations are provided and not just the buffer?

It seems to me that C_AsyncJoin should just join the operation followed by C_AsyncComplete, which will provide all the output pointers/buffers and attempt to complete the operation.

Thanks

Darren

pkcs11 message