[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 On 10/04/2013 9:45 AM, Michael StJohns wrote:
On 4/9/2013 6:06 PM, Tim Hudson wrote:
It's all normative.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]