Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

[Michael StJohns <msj@nthpermutation.com>]

On 4/11/2013 4:47 PM, Tim Hudson wrote:
> And that approach misses the point that we have a mess - the current 
> mechanism as realised in actual implementation is non-interoperable 
> from the point of view of the consumers of PKCS11.
>
> It needs to be fixed. Now is the time to fix it. We are making changes 
> - this is v2.40 - not v2.30 or v2.20.
>
> It is not a no-impact change from the point of view of users - it is 
> leaving the current impact (non-interoperable) in place - and the 
> point of PKCS11 is to have interoperability. 

And you're missing the point that on my laptop I have header files from 
at least three different vendors including the PKCS11 from Java that 
have the values as they currently exist in the 2.20 header files.  
You're saying - just fix the header file and the text so its a 
CK_ULONG.  So we do that and in about a year when this stuff makes it 
through the process, someone ships the new header file with their 
product, but the customer doesn't do an update because he doesn't need 
any features from 2.40...  header mismatch, debugging night mare, 
support costs.

Or the guy is trying to deal with two different types of token/HSM - one 
that implements your fix and one that uses the old 2.20 stuff. How does 
that work?

So - add a new mechanism and new params structure that fixes this 
issue.  If you have a 2.20 client you call the 2.20 mechanism and use 
the 2.20 params.  If you have a 2.40 client you call the 2.40 mechanism 
and use the 2.40 params.  Internal to the HSM this is a simple - hah - 
insignificant - dereference operation based on the value of the 
mechanism type.

I'm opposed to ANY non-backwards change to the header files.  If a 
structure changes, then we give it a new name.  If we need a new 
atttribute, or need a new interpretation for an attribute value, we 
create them.

Mike