[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] Async Operations - comments
Hi Darren, Thanks for the detailed feedback. It is much appreciated.
The big thing that was confusing to me at first is the whole C_AsyncComplete NOT taking input values. My first example had C_AsyncComplete returning CKR_BUFFER_TOO_SMALL and then being called again with a properly sized buffer, but thatâs not how it would work (thank you Dieter for explaining my own proposal to me). If C_AsyncComplete returns CKR_BUFFER_TOO_SMALL, the application needs to call the original function again with a properly sized buffer (C_SignFinal then C_AsyncComplete then C_SignFinal again with proper buffer then C_AsyncComplete). Iâll update the doc with changes for 2 and 5 above and with any changes arising from the next email on the subject 😊 If anyone has suggestions for language on 3 and 6 please send it! Sincerely, Jonathan From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of JOHNSON Darren THIS MESSAGE COMES FROM AN EXTERNAL SOURCE. PLEASE VERIFY THE CONTENTS OF THIS MESSAGE BEFORE PROCEEDING. I missed all the discussions around this proposal. So I apologize if Iâm asking questions that were already discussed and resolved.
I assume the first part, âTokens must support synchronous sessionsâ is going to be removed? Tokens may support async sessions.
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?
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.
This may not be obvious to all readers and should probably be mentioned.
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 |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]