Re: [pkcs11] CKM_PKCS5_PBKD2_PARAMS - straw poll options

[Dina Kurktchi <dina.kurktchi@oracle.com>]

On 04/18/13 07:38, Michael StJohns wrote:

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

Is it useful to add one more bit to the "do not change" part:  suggest
to implementers, that if they have already deviated from header files or
the specification in their own implementations, to leave things lie.
I'm really hoping for a complete deep-freeze for this struct and its
mech.  Don't bother fixing up past deviations, and simply move on with
implementing something brand-new (which looks suspiciously like the
old broken one).  This would be explained in the "annotation".  If
anyone yearns to fix it up anyway, go right ahead -- their consumers
and inter-op issues are their own to deal with.

> 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 was the one at the meeting who mentioned deprecating and replacing
the struct, without necessarily deprecating and replacing "its"
mechanism.  The reason my mind (and thus my mouth) went there is
because I was percolating the idea of mooshing the varied param
structs into something more unified, and shareable between mechs.
But since that idea hasn't taken shape yet, I have no problem
deprecating and replacing both struct and "its" mechanism.  The
idea of a general purpose param struct is completely separable
from this discussion.  So if I'm the only one that felt anything
about #5, you can drop it.  Don't need the extra noise.

Thanks,
D.