OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] 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 <msj@nthpermutation.com> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]