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.

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

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
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.


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:

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