RE: [pkcs11] CKM_PKCS5_PBKD2_PARAMS - straw poll options

[Gil Abel <gil@athena-scs.com>]

I'm in option that option 2 from Michael's list (= 4 from Tim's list), i.e. "deprecate + add new",  is the best option to go as it will not break existing library implementations and application using them, and define a clean mechanism for future use. Obsolete the mechanism seems a too sever action as it will break -any current implementation of this mechanism, no matter how it has interpreted the inconsistency in the specs.

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Michael StJohns
Sent: Friday, April 19, 2013 5:36 AM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] CKM_PKCS5_PBKD2_PARAMS - straw poll options

On 4/18/2013 6:21 PM, John Leiseboer wrote:
> - No change
My number 1
> - Change the field name and description: keep CK_ULONG_PTR
My number 4
> - Deprecate current structure, add new structure definition with CK_ULONG, and add a new mechanism id
My number 2
> - Change the structure definition: change CK_ULONG_PTR to CK_ULONG
My number 3
> - Rename the current structure, add a new mechanism id for it, and change the current structure definition: change CK_ULONG_PTR to CK_ULONG
This one looks like Tim's number 5.

I would state this as:

"Obsolete and remove the current structure and mechanism from the text 
and header file.  Replace it with a new mechanism (with a new name) and 
new param  structure. "  That will require in addition [Annotate the 
text to indicate the removal of the old mechanism. Retain the CKM_ 
mechanism value in the header file (to ensure the value isn't reused)]"

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