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

[Michael StJohns <msj@nthpermutation.com>]

On 4/13/2013 1:07 AM, Tim Hudson wrote:
> On 13/04/2013 11:20 AM, Michael StJohns wrote:
> > Fix attached.
> That isn't a "fix" - that's a way to keep the problem repeating itself
> again and again.
>
> The existing structure should be renamed
Instead I added a new structure to fix the problem, leaving the existing 
one in place.  The new name is:

CK_PKCS5_PBKD2_FIX_PARAMS
> and the mechanism value changed
CKM_PKCS5_PBKD2_FIX
> so that new users of the 2.40 header files get the right usage.
> To use a deprecated mechanism should require code changes in the
> consumers of the interface.
As someone else pointed out (Robert?) client implementations and server 
implementations do not change in step.  If I've got an implementation 
(client side) that's talking perfectly well to Vendor A's server side, I 
don't want it to break if I update the Vendor A driver to PKCS11 V2.40.

If I've got a new client and I'm starting from 2.40, I need to add code 
to check the version of the driver/server and act accordingly, using the 
old 2.20 interface for 2.20 servers and the new interface for 2.40 
servers.  I *may* need to also figure out whether I'm talking to a 
server that uses the un-edited interface, or the edited interface, but I 
may not ever care.


> We do not want any usage of the broken (non-interoperable) interface to
> occur for users who recompile existing consumers of the API against the
> v2.40 header file.
I don't understand what you're trying to say here.

There are clients who implement for the general case and use the header 
files right off of the PKCS11 web page.  They are interoperable (at 2.20 
and 2.30 ) with any server that used the un-edited header files.  That 
specifically includes the IAIK and the Java JDK (derived from IAIK a 
while back) client interfaces, and I believe NSS.


> This isn't a gentle deprecation content - anyone using the interface
> that isn't completely sure that both the producer and consumer of the
> interface have exactly the same interpretation is non-interoperable -
> this interface is simply broken.
Yes but - there are probably 1000s of implementations where either both 
sides have the original header files, or both sides have the edited 
files and work perfectly fine.  I see no benefit and a hell of a lot of 
downside to breaking that.

If you want to enforce this from a server point of view for your 
products, feel free to comment out the old definitions in the header 
files you provide to customers, and/or remove support for the old 
mechanism from your products.

I don't see that decisions on your products need to adversely affect others.

> Changing the mechanism value to a new one so that previous binary users
> of the interface can continue to hope that it works with the same level
> of non-guarantee as currently will be supported.
There's something wrong with the above sentence.  I can't parse what 
you're trying to say - if you remove the intermediate clauses it seems 
to say "Changing the mechanism value to a new one will be supported".
> So a producer of the
> API can support both old and new interfaces (accepting
> non-interoperability) but v2.40 and beyond get sorted out.
And at this point, I no longer understand your objection to my "fix"?  
The fix contains both old and new mechanisms and structures.

Mike

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