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: CKM_PKCS5_PBKD2_PARAMS - straw poll options


I'm not sure I have these correct. The first two I'm pretty sure of, the last two/three not so much.


1) Do almost nothing. Do not change the struct in either the text or header. Annotate the mechanism description to point out the possible issue.

2) Deprecate the bug. Do not change the current struct in either the text or the header. Annotate the existing mechanism describing the current issue. Deprecate the existing mechanism. Deprecate the existing struct. Create a new mechanism and new struct (with new names) that changes the type of ulPasswordLen from CK_ULONG_PTR to CK_ULONG.

3) Fix the declaration. Update the existing struct changing CK_ULONG_PTR to CK_ULONG. Change the header file to match. Update any text and descriptions to match. Annotate the change in the text.

4) Fix the textual convention. Update the existing struct changing the name of ulPasswordLen to pulPasswordLen to agree with CK_ULONG_PTR as the type. Update any text and descriptions to match. Annotate the change in the text.

5) Something else? I heard something like deprecate the struct without deprecating the mechanism and vice versa, but given that the mechanism type defines the type of the param field in the mechanism struct I'm not sure how that would work.

I'll reserve further comments on this entire topic until we have the appropriate set of choices. I would suggest that whoever supports/proposes one of the choices MUST be the stuckee for providing appropriate edited text as I've already done for (2).

I think this is now in Valerie's hand to manage the formation of the straw poll.









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