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
