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

I think we all agree that CK_ULONG_PTR was a typo. The issue is now an argument around what to do about it: nothing, change the text, change the C definition.

The following comes from the PKCS#11 specification (my emphasis):

“This document specifies the data types and functions available to an application requiring

cryptographic services using the ANSI C programming language. These data types and

functions will typically be provided via C header files by the supplier of a Cryptoki

library. Generic ANSI C header files for Cryptoki are available from the PKCS Web

page.”

I interpret this to mean that the (normative) specification is given in the snippets of C that appear in the specification, and hopefully are reproduced without error in the header files. So even if there is a typo in the C code, precedence of interpretation is given to the C code definitions. (And by the way this is consistent with other standards that are specified using both text and code; e.g. IEEE 802.1d, and various XML-based specifications. 802.1d explicitly states the precedence rules for interpretation of the standard. PKCS#11 doesn’t.)

I haven’t offered an opinion on what we should do about it, but I think that it is important to recognise that the C code is the specification. So we are not talking about simply correcting a typo. We are talking about potentially changing the specification versus modifying, or adding to, the text to be consistent with the C code specification.

John

From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Wednesday, 10 April 2013 10:03 AM
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.

pkcs11 message