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

[Michael StJohns <msj@nthpermutation.com>]

On 4/10/2013 1:53 PM, Burns, Robert wrote:

I think that because we are on the precipice of publishing this as an OASIS standard, now would be a good time to take care of these issues and fix obvious flaws.  This is a good ‘edge-condition’ by which we can justify to the user base that changes need to be made.  Although it is a change, it should be manageable and improve the usability in the long run.

 

Bob

Let's make a no impact change.

Define a new mechanism and mechanism param that fixes this.  Leave the other one alone.  Foot note the text to explain what we did.  Deprecate the old one - say it will go away with PKCS11 3.0.

It's about5 minutes work cut and paste.

Mike

rom: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Tuesday, April 09, 2013 8:03 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

 

On 10/04/2013 9:45 AM, Michael StJohns wrote:

On 4/9/2013 6:06 PM, Tim Hudson wrote:

It's all normative.
Try doing anything meaningful in the way of interpretation without what you are suggesting is merely informative text.

Umm.. let me try this a slightly different way.  The header files - in a way nothing else is in this spec - are *really* normative in that they mostly just get compiled in.  They - more than anything else are the ICD between the HSM and the client code.

But the header files are not in the specification - and they were not included in the updated contribution and haven't been maintained or updated for v2.30 except in an ad-hoc manner and vendors clearly saw errors in the file and have corrected them. Not an unreasonable position to take. I do think the header files should be published as part of the specification - but they currently are not. The header files currently contain information not contained within the specification (the comments and various macros).

And on top of that vendors are free to provide their own header files (completely different or modified) and do - there is no requirement to use the ad-hoc provided RSA header files in order for it to be called PKCS#11. That's about as clearly non-normative as you can get.

Logically it makes no sense for that value to be a CK_ULONG_PTR - it should be a CK_ULONG - it is a plain simple typographical error in the specification which should be fixed.

We have three items in the specification - the type (one item) which conflicts with the field name and the description (two items). The field name and description align (and agree) and the type does not. The use of a CK_ULONG_PTR here is inconsistent with other parts of the specification and frankly is illogical.

It is just plain wrong and should be fixed. We have vendors who have taken different approaches. It makes for any application using this mechanism to be non-portable and non-interoperable. It should be fixed.

Arguing that one of the conflicting items overrides the others misses the point that the interface is plain wrong and implemented differently by different vendors and hence needs to be fixed.

Tim.