Groups - Slides: PKCS #11 AEAD Functions at 2014-02-28 F2F uploaded

Hi Mike, Thank you again for your comments on the PDF file of my proposal.
On Tuesday, March 25, I revised the proposal to address some of your comments.
Here are my responses to your other comments.
1. Re: the new const pointer types CK_CONST_BYTE_PTR and CK_CONST_VOID_PTR I don't need to introduce the new const pointer types in this proposal.
I proposed the use of const pointers at the F2F meeting in Santa Clara, CA last year, so I thought I should start using them.
2. Re: the CK_ULONG ulParameterLen parameter of C_EncryptMessage: Your suggestion of declaring this parameter as CK_ULONG_PTR pulParameterLen is interesting.
I modeled the pParameter and ulParameterLen parameters of C_EncryptMessage after the pParameter and ulParameterLen fields of the CK_MECHANISM structure, so I declare them to have the exact same types.
In the two concrete IV generator mechanisms I specified, the expected length of the IV output is known, so the generated IV length doesn't need to be an output parameter.
I believe this is the common case, so using CK_ULONG_PTR pulParameterLen should be fine.
Since pParameter is a void * pointer, it can point to a structure containing a length field that C_EncryptMessage can set.
So the flexibility is there if the need arises.
3. Re: whether an association object should be explicitly marked as Encrypt, Decrypt, Sign, or Verify: This issue has been discussed separately on this email thread.
I didn't change this aspect of the proposal.
Thanks, Wan-Teh Chang On Sun, Mar 16, 2014 at 5:41 PM, Michael StJohns < 
> wrote: On 2/28/2014 12:52 PM, Wan-Teh Chang wrote: Submitter's message I will be using these slides for my talk on PKCS #11 AEAD functions at the F2F meeting today.

--
Wan-Teh Chang Document Name : Slides: PKCS #11 AEAD Functions at 2014-02-28 F2F Description Wan-Teh Chang's presentation slides on PKCS #11 AEAD functions at the F2F meeting on 2014-02-28 Download Latest Revision Public Download Link Submitter : Wan-Teh Chang Group : OASIS PKCS 11 TC Folder : Documents Date submitted : 2014-02-28 09:52:38 I did a review pass on the spec document for this proposal, not the slides (couldn't find the email announcing the upload so I could reply to it) and the annotated version is attached.
It's getting closer to my proposal and I noted some areas where it still needs improvement.
I wouldn't go forward with this without adding the message based calls for Sign and Verify for example.
With respect to the API, I wouldn't attempt to reuse any current API calls to implement either AEAD or message based stuff.
The hard decision is to open up the API to change - once you do that its simply a matter of crafting the set of calls that you need rather than trying to impedence match the new functions to the old API.
With respect to the proposal, I think a single pair of C_NewAssociation and C_CloseAssociation API calls will work to cover all of encrypt, decrypt, sign and verify rather than C_NewEncryptAssociation, C_NewSignAssociation etc....
If you think of the C_EncryptMessage and C_SignMessage as macros for a C_EncryptInit/C_Encrypt which use data from the association, I can't see any reason why you need a new association function per message type.
Mike

---------------------------------------------------------------------

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