pkcs11 — archive

[Tim Hudson]

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.