OASIS PKCS 11 TC

Dina seems to just be an observer right now, so I'm forwarding this message on her behalf of what seems to be a typo in the standard that has caused potential bugs in implementations. Valerie

Exact structure from our v2.10 'virgin' pkcs11t.h file shows the error as well, along with conflicting naming using the ‘ul’ construct:   /* CK_PKCS5_PBKD2_PARAMS is new for v2.10. * CK_PKCS5_PBKD2_PARAMS is a structure that provides the * parameters to the CKM_PKCS5_PBKD2 mechanism. */ typedef struct CK_PKCS5_PBKD2_PARAMS {         CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE           saltSource;         CK_VOID_PTR                                pSaltSourceData;         CK_ULONG                                   ulSaltSourceDataLen;         CK_ULONG                                   iterations;         CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE prf;         CK_VOID_PTR                                pPrfData;         CK_ULONG                                   ulPrfDataLen;         CK_UTF8CHAR_PTR                            pPassword;         CK_ULONG_PTR                               ulPasswordLen; } CK_PKCS5_PBKD2_PARAMS;   Does the question now become one of backwards compatibility if we have some vendors who fixed the flaw, and others who implemented it as documented and declared in the previously published headers?   Bob   >
Original Message----- > From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On > Behalf Of Valerie Anne Fenwick > Sent: Wednesday, April 03, 2013 6:04 PM > To: pkcs11@lists.oasis-open.org > Cc: Dina Kurktchi > Subject: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length > > > Dina seems to just be an observer right now, so I'm forwarding this message > on her behalf of what seems to be a typo in the standard that has caused > potential bugs in implementations. > > Valerie > >

On 4/04/2013 8:25 AM, Burns, Robert wrote: Exact structure from our v2.10 'virgin' pkcs11t.h file shows the error as well, along with conflicting naming using the ‘ul’ construct:   /* CK_PKCS5_PBKD2_PARAMS is new for v2.10. * CK_PKCS5_PBKD2_PARAMS is a structure that provides the * parameters to the CKM_PKCS5_PBKD2 mechanism. */ typedef struct CK_PKCS5_PBKD2_PARAMS { ...         CK_ULONG_PTR                               ulPasswordLen; } CK_PKCS5_PBKD2_PARAMS;   Does the question now become one of backwards compatibility if we have some vendors who fixed the flaw, and others who implemented it as documented and declared in the previously published headers? We have a mix in the implementations I've seen (just took another pass through the various vendor header files): 1) corrected the clearly erroneous header file to have CK_ULONG 2) left incorrect header file as-is but implemented as thought it is a CK_ULONG instead of CK_ULONG_PTR 3) implemented with that type actually as a pointer to the value ignoring the 'ul' prefix indicator That typographical error (that's certainly how I view it) remains in the v2.30 draft header files. See http://www.cryptsoft.com/pkcs11doc/ as a handy reference to the PKCS#11 documents and their corresponding header files. What this means is that we have a non-interoperable situation at the moment and that going forward someone will have to change their implementation. I suggest a straw poll on the solution as the simple path forward as I doubt a consensus will exist given that it will impact products. Tim.

On 04/03/2013 03:25 PM, Burns, Robert wrote: Exact structure from our v2.10 'virgin' pkcs11t.h file shows the error as well, along with conflicting naming using the ‘ul’ construct:   /* CK_PKCS5_PBKD2_PARAMS is new for v2.10. * CK_PKCS5_PBKD2_PARAMS is a structure that provides the * parameters to the CKM_PKCS5_PBKD2 mechanism. */ typedef struct CK_PKCS5_PBKD2_PARAMS {         CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE           saltSource;         CK_VOID_PTR                                pSaltSourceData;         CK_ULONG                                   ulSaltSourceDataLen;         CK_ULONG                                   iterations;         CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE prf;         CK_VOID_PTR                                pPrfData;         CK_ULONG                                   ulPrfDataLen;         CK_UTF8CHAR_PTR                            pPassword;         CK_ULONG_PTR                               ulPasswordLen; } CK_PKCS5_PBKD2_PARAMS;   Does the question now become one of backwards compatibility if we have some vendors who fixed the flaw, and others who implemented it as documented and declared in the previously published headers?   Bob I've checked our implementation, and we treat it as a CK_ULONG_PTR, just as the spec and header file specify, even though it's clearly a typo. bob Attachment: smime.p7s Description: S/MIME Cryptographic Signature

On 4/8/2013 3:13 PM, Robert Relyea wrote: On 04/03/2013 03:25 PM, Burns, Robert wrote: Exact structure from our v2.10 'virgin' pkcs11t.h file shows the error as well, along with conflicting naming using the ‘ul’ construct:   /* CK_PKCS5_PBKD2_PARAMS is new for v2.10. * CK_PKCS5_PBKD2_PARAMS is a structure that provides the * parameters to the CKM_PKCS5_PBKD2 mechanism. */ typedef struct CK_PKCS5_PBKD2_PARAMS {         CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE           saltSource;         CK_VOID_PTR                                pSaltSourceData;         CK_ULONG                                   ulSaltSourceDataLen;         CK_ULONG                                   iterations;         CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE prf;         CK_VOID_PTR                                pPrfData;         CK_ULONG                                   ulPrfDataLen;         CK_UTF8CHAR_PTR                            pPassword;         CK_ULONG_PTR                               ulPasswordLen; } CK_PKCS5_PBKD2_PARAMS;   Does the question now become one of backwards compatibility if we have some vendors who fixed the flaw, and others who implemented it as documented and declared in the previously published headers?   Bob I've checked our implementation, and we treat it as a CK_ULONG_PTR, just as the spec and header file specify, even though it's clearly a typo. bob I'd leave it as is.  It's consistent in the text and in the header files.   If it needs to be changed, then the proper way is to define a new structure and mechanism and leave this one intact. Mike

On 10/04/2013 7:36 AM, Michael StJohns wrote: I'd leave it as is.  It's consistent in the text and in the header files.   If it needs to be changed, then the proper way is to define a new structure and mechanism and leave this one intact. And I'm going to have to disagree here - in that the text itself does not support the typographical error in the structure definition. It states: ulPasswordLen           length in bytes of the password information X-NONE X-NONE MicrosoftInternetExplorer4 All the other references to CK_ULONG_PTR have a clear description along these lines: pulOutputLen            pointer to the length in bytes that the output to be created shall have, has to hold the desired length as input and will receive the calculated length as output That the prose did not state pointer to means that it is not documented as being a pointer reference. And yes I do realise that there are other references to pointer types which don't start with pointer in their description (and they should) but there are only three CK_ULONG_PTR references in mechanism parameters - and the other two explicitly state pointer to . Those descriptions that don't state pointer to that are actually pointers should be updated IMHO - the vast majority of items in the specification explicitly state pointer to - but there are some exceptions. It's unfortunate that no one has raised this before as clearly vendors have noticed it and made a choice (one way or the other). Leaving this little mess alone and not fixing it wouldn't be my preference - this like this which are clearly being interpreted differently by vendors should be fixed and now is the right time to fix it before we cement this in an OASIS specification. Tim.

On 4/9/2013 5:48 PM, Tim Hudson wrote: On 10/04/2013 7:36 AM, Michael StJohns wrote: I'd leave it as is.  It's consistent in the text and in the header files.   If it needs to be changed, then the proper way is to define a new structure and mechanism and leave this one intact. And I'm going to have to disagree here - in that the text itself does not support the typographical error in the structure definition. It states: ulPasswordLen           length in bytes of the password information I'd claim that the CK_ULONG_PTR declaration is normative, while the ulPasswordLen  component name and descriptive text are informative. If you want to fix the informative text, I'm OK with that.  I'd probably annotate this change as a footnote.  I wouldn't change the structure definition in either the text or the header.  I probably wouldn't change the name of the structure component either. Mike X-NONE X-NONE MicrosoftInternetExplorer4 All the other references to CK_ULONG_PTR have a clear description along these lines: pulOutputLen            pointer to the length in bytes that the output to be created shall have, has to hold the desired length as input and will receive the calculated length as output That the prose did not state pointer to means that it is not documented as being a pointer reference. And yes I do realise that there are other references to pointer types which don't start with pointer in their description (and they should) but there are only three CK_ULONG_PTR references in mechanism parameters - and the other two explicitly state pointer to . Those descriptions that don't state pointer to that are actually pointers should be updated IMHO - the vast majority of items in the specification explicitly state pointer to - but there are some exceptions. It's unfortunate that no one has raised this before as clearly vendors have noticed it and made a choice (one way or the other). Leaving this little mess alone and not fixing it wouldn't be my preference - this like this which are clearly being interpreted differently by vendors should be fixed and now is the right time to fix it before we cement this in an OASIS specification. Tim.

On 10/04/2013 8:03 AM, Michael StJohns wrote: I'd claim that the CK_ULONG_PTR declaration is normative, while the ulPasswordLen  component name and descriptive text are informative. If you want to fix the informative text, I'm OK with that.  I'd probably annotate this change as a footnote.  I wouldn't change the structure definition in either the text or the header.  I probably wouldn't change the name of the structure component either. It's all normative. Try doing anything meaningful in the way of interpretation without what you are suggesting is merely informative text. Tim.

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. The field name- specifically the naming convention ulPasswordLength vs pulPasswordLength isn't going to be interpreted by the compiler. The text in the body of the document that describes the field as "length of password" vs "pointer to length of password" isn't going to be seen by the compilers, and a good compiler is going to flag the use of a long vs a pointer to an long during the compile. So given the choice between confusing humans - slightly - and putting out two different versions of the same structure in a header file and confusing the computers, I'd rather confuse the humans, especially since we can add comments to both the header file and the spec to describe what happened. Or again, we change the name of the structure, deprecate the current version in the header file, deprecate the mechanisms that use the current version, create new mechanisms that do exactly the same as the old mechanisms but with a CK_ULONG instead of CK_ULONG_PTR in the appropriate place. Mike

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.

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.

Check the OASIS rules for specification consistency and conflicts between document text and external files (schemas, programming-language codes for some purpose, etc.). An OASIS PKCS#11 specification needs to align with that. With regard to in-text inclusion of code snippets, it is important to identify their standing and also deal with any conflicts between any "normative" snippets and normative statements in the text. - Dennis PS: I am not a believer, generally, that code is the specification. However, if that is intended there is a new task: It is necessary to normatively rely on the programming language chosen and deal with profiling of the language elements used where its specification is silent or dependent on agreements beyond that specification. PPS: The objective for a specification that is intended to support interoperable implementations is that such a specification-conformant, interoperable implementation can be achieved without having to consult an implementation. There are the usual caveats about what skills and level of art are required for accomplishing that with the specification.
Original Message----- From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of John Leiseboer Sent: Tuesday, April 09, 2013 22:32 To: pkcs11@lists.oasis-open.org Subject: RE: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length [ ... ] 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 [ ... ]

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   From: 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.

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.

On 12/04/2013 6:34 AM, Michael StJohns wrote: 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. And that approach misses the point that we have a mess - the current mechanism as realised in actual implementation is non-interoperable from the point of view of the consumers of PKCS11. It needs to be fixed. Now is the time to fix it. We are making changes - this is v2.40 - not v2.30 or v2.20. It is not a no-impact change from the point of view of users - it is leaving the current impact (non-interoperable) in place - and the point of PKCS11 is to have interoperability. Tim.

On 4/11/2013 4:47 PM, Tim Hudson wrote: And that approach misses the point that we have a mess - the current mechanism as realised in actual implementation is non-interoperable from the point of view of the consumers of PKCS11. It needs to be fixed. Now is the time to fix it. We are making changes - this is v2.40 - not v2.30 or v2.20. It is not a no-impact change from the point of view of users - it is leaving the current impact (non-interoperable) in place - and the point of PKCS11 is to have interoperability. And you're missing the point that on my laptop I have header files from at least three different vendors including the PKCS11 from Java that have the values as they currently exist in the 2.20 header files. You're saying - just fix the header file and the text so its a CK_ULONG. So we do that and in about a year when this stuff makes it through the process, someone ships the new header file with their product, but the customer doesn't do an update because he doesn't need any features from 2.40... header mismatch, debugging night mare, support costs. Or the guy is trying to deal with two different types of token/HSM - one that implements your fix and one that uses the old 2.20 stuff. How does that work? So - add a new mechanism and new params structure that fixes this issue. If you have a 2.20 client you call the 2.20 mechanism and use the 2.20 params. If you have a 2.40 client you call the 2.40 mechanism and use the 2.40 params. Internal to the HSM this is a simple - hah - insignificant - dereference operation based on the value of the mechanism type. I'm opposed to ANY non-backwards change to the header files. If a structure changes, then we give it a new name. If we need a new atttribute, or need a new interpretation for an attribute value, we create them. Mike

On 12/04/2013 7:04 AM, Michael StJohns wrote: > On 4/11/2013 4:47 PM, Tim Hudson wrote: >> And that approach misses the point that we have a mess - the current >> mechanism as realised in actual implementation is non-interoperable >> from the point of view of the consumers of PKCS11. >> >> It needs to be fixed. Now is the time to fix it. We are making >> changes - this is v2.40 - not v2.30 or v2.20. >> >> It is not a no-impact change from the point of view of users - it is >> leaving the current impact (non-interoperable) in place - and the >> point of PKCS11 is to have interoperability. > > And you're missing the point that on my laptop I have header files > from at least three different vendors including the PKCS11 from Java > that have the values as they currently exist in the 2.20 header > files. You're saying - just fix the header file and the text so its a > CK_ULONG. And I've got three vendors who have changed it and two who have just placed a long and not used it as a pointer on one test configuration here. It's a mess. It needs fixing. Multiple vendors have indicated they corrected the clear mistake in the header files - leaving it alone is basically not a sensible option. Anyone currently using that mechanism is non-interoperable. I'm saying in PKCS11 v2.30 we can fix this - it is a new version - and we have not as a committee elected to make no changes and to require completely binary compatibility with previous (non-OASIS) versions. Tim.

On 04/11/13 02:27 PM, Tim Hudson wrote: On 12/04/2013 7:04 AM, Michael StJohns wrote: On 4/11/2013 4:47 PM, Tim Hudson wrote: And that approach misses the point that we have a mess - the current mechanism as realised in actual implementation is non-interoperable from the point of view of the consumers of PKCS11. It needs to be fixed. Now is the time to fix it. We are making changes - this is v2.40 - not v2.30 or v2.20. It is not a no-impact change from the point of view of users - it is leaving the current impact (non-interoperable) in place - and the point of PKCS11 is to have interoperability. And you're missing the point that on my laptop I have header files from at least three different vendors including the PKCS11 from Java that have the values as they currently exist in the 2.20 header files. You're saying - just fix the header file and the text so its a CK_ULONG. And I've got three vendors who have changed it and two who have just placed a long and not used it as a pointer on one test configuration here. It's a mess. It needs fixing. Multiple vendors have indicated they corrected the clear mistake in the header files - leaving it alone is basically not a sensible option. Anyone currently using that mechanism is non-interoperable. I'm saying in PKCS11 v2.30 we can fix this - it is a new version - and we have not as a committee elected to make no changes and to require completely binary compatibility with previous (non-OASIS) versions. I agree. We are making a quick revision to fix past mistakes. It seems nobody disagrees this was a mistake (typo) in previous drafts. The fact that we've all implemented this differently means we're already at risk for losing compatibility. Now, for us, on 64 bit machines, ulong and a ulong pointer are the same size. So, we are happy to go with either and make the necessary bug fixes. I know that's not the same for everyone. So, I'm strongly in favor of correcting the typo, but don't really care which way it goes. Valerie -- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic Technologies, Manager, Oracle Corporation 4180 Network Circle, Santa Clara, CA, 95054.

On 04/11/2013 02:27 PM, Tim Hudson wrote: On 12/04/2013 7:04 AM, Michael StJohns wrote: On 4/11/2013 4:47 PM, Tim Hudson wrote: And that approach misses the point that we have a mess - the current mechanism as realised in actual implementation is non-interoperable from the point of view of the consumers of PKCS11. It needs to be fixed. Now is the time to fix it. We are making changes - this is v2.40 - not v2.30 or v2.20. It is not a no-impact change from the point of view of users - it is leaving the current impact (non-interoperable) in place - and the point of PKCS11 is to have interoperability. And you're missing the point that on my laptop I have header files from at least three different vendors including the PKCS11 from Java that have the values as they currently exist in the 2.20 header files. You're saying - just fix the header file and the text so its a CK_ULONG. And I've got three vendors who have changed it and two who have just placed a long and not used it as a pointer on one test configuration here. It's a mess. It needs fixing. Multiple vendors have indicated they corrected the clear mistake in the header files - leaving it alone is basically not a sensible option. So I agree it's a mess. I agree that it was a typo. But I also know if we "fix" the typo and keep the same mechanism number, I am completely hosed. I have both a library and a module. Because of FIPS they don't get updates in sync. I have binary compatibility requirements to maintain. I'm not allow to have modules that work with my code today suddenly start crashing. Anyone who implemented this could not help but notice that it was a typo, but because it was a typo and consistent in both the header and the spec, we felt we had to follow the spec not matter how weird it seemed. Now fast forward. We all agree it was a typo, but now have running code that depends on that type. I can't just change the header because it affects what happens in my binaries. I can't break modules that are already working today to fix modules that are crashing. Even worse, I can't always update my own PKCS #11 module on some of my platforms because of FIPS, so if I change my library, I will now crash on those platforms against my own PKCS #11 module. Obviously that can't happen. I'm sure I'm not the only one in this position. Switching the spec so that it's clearly a pointer to the length (by changing the variable name) doesn't help because someone else is in exactly my same boat, only the depend on different behavior. The only way forward is to abandon this mechanism number and we all go to a new mechanism that has the fixed typo. My library can then try the new mechanism first, and then fall back to the old one (which the way we interpreted the old mechanism). Now my updates don't need to be sync'd. I don't break old modules that did work with me before, but I have a prayer of getting all the new modules to work with me. No new crashes, the end game is something that we are all happily interoperating. The spec updates are: new mechanism (I'd also prefer a new name for the mechanism and structure, but that's not quite as critical as I can work around this). The old one is deprecated. You don't make a new implementation of the old mechanism. The documentation may actually simply say 'This mechanism is deprecated. In the field different implementations have different interpretations of the meanings of the parameters, so use of this mechanism is unreliable.' and nothing else. bob Anyone currently using that mechanism is non-interoperable. I'm saying in PKCS11 v2.30 we can fix this - it is a new version - and we have not as a committee elected to make no changes and to require completely binary compatibility with previous (non-OASIS) versions. 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 Attachment: smime.p7s Description: S/MIME Cryptographic Signature

+1 …. to correct the header per Tim’s proposal  below. The use of CK_ULONG_PTR in is clearly a typo and, I can attest that we already ship  implementations  where we treat it as a CK_ULONG instead of CK_ULONG_PTR  regardless of the typo. While I understand the issue is backwards compatibility, and that other implementations follow the C header as is ,  I would also claim that in  reality implementers have already made choices and there is significant inconsistency in the market which causes interoperability issues regardless. So, since we are here with the goal of updating  the spec , my preference is that we  SHOULD make it right and consistent with the wording (and rest of the spec) in 2.40 . Doron       On 10/04/2013 7:36 AM, Michael StJohns wrote: I'd leave it as is.  It's consistent in the text and in the header files.   If it needs to be changed, then the proper way is to define a new structure and mechanism and leave this one intact. And I'm going to have to disagree here - in that the text itself does not support the typographical error in the structure definition. It states: ulPasswordLen           length in bytes of the password information All the other references to CK_ULONG_PTR have a clear description along these lines: pulOutputLen            pointer to the length in bytes that the output to be created shall have, has to hold the desired length as input and will receive the calculated length as output That the prose did not state " pointer to " means that it is not documented as being a pointer reference. And yes I do realise that there are other references to pointer types which don't start with pointer in their description (and they should) but there are only three CK_ULONG_PTR references in mechanism parameters - and the other two explicitly state "pointer to". Those descriptions that don't state pointer to that are actually pointers should be updated IMHO - the vast majority of items in the specification explicitly state pointer to - but there are some exceptions. It's unfortunate that no one has raised this before as clearly vendors have noticed it and made a choice (one way or the other). Leaving this little mess alone and not fixing it wouldn't be my preference - this like this which are clearly being interpreted differently by vendors should be fixed and now is the right time to fix it before we cement this in an OASIS specification. Tim. The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

On 04/09/2013 11:43 PM, Cohen, Doron wrote: +1 …. to correct the header per Tim’s proposal  below. The use of CK_ULONG_PTR in is clearly a typo and, I can attest that we already ship  implementations  where we treat it as a CK_ULONG instead of CK_ULONG_PTR  regardless of the typo. While I understand the issue is backwards compatibility, and that other implementations follow the C header as is ,  I would also claim that in  reality implementers have already made choices and there is significant inconsistency in the market which causes interoperability issues regardless. So, since we are here with the goal of updating  the spec , my preference is that we  SHOULD make it right and consistent with the wording (and rest of the spec) in 2.40 . Doron The one issue is how much and who gets broken. A library* could presumably, possibly detect that the value passed in the CK_ULONG_PTR is really a CK_ULONG (assuming that input to a pbe is likely to be small compared to a random memory address), but it's not reliable (on some platforms the address could be passed in as text). There is a compatibility issue here. NSS has been using CK_ULONG_PTR for quite some time, so pretty much every version of Firefox would expect the value to be CK_ULONG_PTR, which means if your token supports key import, any AES encoded PKCS #12 file could crash your PKCS #11 module (and thus a browser) if you try to import it into the token. I'm personally coming to the conclusion we need to deprecate this mechanism number and make a new one that fixes this typo. The reason was some modules/libraries followed that the spec meant while others followed what the spec said. This allows library/module pairs that used to work together to continue to work, while all new libraries module pairs will work properly, and spreads the compatibility issues evenly. Upshot: 1) define a new mechanism number, which takes the correct data structure. 2) mark the old one a depricated. If a library/module has already implemented this mechanism, that library or module should continue to use the understanding it already has. New libraries and modules should not implement the old mechanism. I think this preserves the best case for interoperability (old module/library pairs that worked together continue to work together, old ones that conflict will continue to conflict. Updated versions of all the libraries and modules [including the previously conflicting ones will continue to work together]) As both a library implementer and a module implementer I know how I can move forward without breaking my world if the library or module gets updated out of sync (which happens regularly, and sometimes by design in NSS). bob *I use library to mean The code that talks to the PKCS #11 module . Some use application , but for me that masks the fact that applications typically don't talk directly to PKCS #11 modules, but to crypto libraries that talk directly to PKCS #11 modules. I use the term module to mean the actual PKCS #11 DLL/so to distinguish it from the crypto library that talks to it. I'm wondering if we need to invent less confusing nominclature here to distinguish the PCKS #11 caller from the PKCS #11 implementation. bob       On 10/04/2013 7:36 AM, Michael StJohns wrote: I'd leave it as is.  It's consistent in the text and in the header files.   If it needs to be changed, then the proper way is to define a new structure and mechanism and leave this one intact. And I'm going to have to disagree here - in that the text itself does not support the typographical error in the structure definition. It states: ulPasswordLen           length in bytes of the password information All the other references to CK_ULONG_PTR have a clear description along these lines: pulOutputLen            pointer to the length in bytes that the output to be created shall have, has to hold the desired length as input and will receive the calculated length as output That the prose did not state pointer to means that it is not documented as being a pointer reference. And yes I do realise that there are other references to pointer types which don't start with pointer in their description (and they should) but there are only three CK_ULONG_PTR references in mechanism parameters - and the other two explicitly state pointer to . Those descriptions that don't state pointer to that are actually pointers should be updated IMHO - the vast majority of items in the specification explicitly state pointer to - but there are some exceptions. It's unfortunate that no one has raised this before as clearly vendors have noticed it and made a choice (one way or the other). Leaving this little mess alone and not fixing it wouldn't be my preference - this like this which are clearly being interpreted differently by vendors should be fixed and now is the right time to fix it before we cement this in an OASIS specification. Tim. The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. Attachment: smime.p7s Description: S/MIME Cryptographic Signature

I concur on first principles. For example, If PKCS#11 were already an OASIS standard, this could not be fixed with an Errata because it would break implementations. If it were fixed by a (necessarily) implementation-breaking change in a future version, and there was no reliable backward compatibility case, deprecating the unfortunate feature and introducing a newly-identified feature strikes me as the appropriate way forward. - Dennis PS: When HTML-formatted messages are X.509-signed, there is no companion plaintext for those readers that are configured to read all mail in plaintext. I strongly urge that X.509-signed messages sent to the PKCS#11 list be in plaintext. The list server does manage to preserve the HTML message, but not in verifiable form of course, < https://lists.oasis-open.org/archives/pkcs11/201304/msg00065.html >. It is fortunate that there are no digest subscriptions. Digests generally make a mess of mixed plaintext and HTML messages. From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of Robert Relyea Sent: Friday, April 12, 2013 13:47 To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length [ … ] I'm personally coming to the conclusion we need to deprecate this mechanism number and make a new one that fixes this typo. The reason was some modules/libraries followed that the spec meant while others followed what the spec said. This allows library/module pairs that used to work together to continue to work, while all new libraries module pairs will work properly, and spreads the compatibility issues evenly. Upshot: 1) define a new mechanism number, which takes the correct data structure. 2) mark the old one a depricated. If a library/module has already implemented this mechanism, that library or module should continue to use the understanding it already has. New libraries and modules should not implement the old mechanism. I think this preserves the best case for interoperability (old module/library pairs that worked together continue to work together, old ones that conflict will continue to conflict. Updated versions of all the libraries and modules [including the previously conflicting ones will continue to work together]) As both a library implementer and a module implementer I know how I can move forward without breaking my world if the library or module gets updated out of sync (which happens regularly, and sometimes by design in NSS). bob [ … ]

Fix attached. Mike On 4/12/2013 8:27 PM, Dennis E. Hamilton wrote: I concur on first principles. For example, If PKCS#11 were already an OASIS standard, this could not be fixed with an Errata because it would break implementations. If it were fixed by a (necessarily) implementation-breaking change in a future version, and there was no reliable backward compatibility case, deprecating the unfortunate feature and introducing a newly-identified feature strikes me as the appropriate way forward. - Dennis PS: When HTML-formatted messages are X.509-signed, there is no companion plaintext for those readers that are configured to read all mail in plaintext. I strongly urge that X.509-signed messages sent to the PKCS#11 list be in plaintext. The list server does manage to preserve the HTML message, but not in verifiable form of course, < https://lists.oasis-open.org/archives/pkcs11/201304/msg00065.html >. It is fortunate that there are no digest subscriptions. Digests generally make a mess of mixed plaintext and HTML messages. From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of Robert Relyea Sent: Friday, April 12, 2013 13:47 To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length [ … ] I'm personally coming to the conclusion we need to deprecate this mechanism number and make a new one that fixes this typo. The reason was some modules/libraries followed that the spec meant while others followed what the spec said. This allows library/module pairs that used to work together to continue to work, while all new libraries module pairs will work properly, and spreads the compatibility issues evenly. Upshot: 1) define a new mechanism number, which takes the correct data structure. 2) mark the old one a depricated. If a library/module has already implemented this mechanism, that library or module should continue to use the understanding it already has. New libraries and modules should not implement the old mechanism. I think this preserves the best case for interoperability (old module/library pairs that worked together continue to work together, old ones that conflict will continue to conflict. Updated versions of all the libraries and modules [including the previously conflicting ones will continue to work together]) As both a library implementer and a module implementer I know how I can move forward without breaking my world if the library or module gets updated out of sync (which happens regularly, and sometimes by design in NSS). bob [ … ] --------------------------------------------------------------------- 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 Attachment: pkcs11-pbkd2-fix.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

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 and the mechanism value changed 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. 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. 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. 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. So a producer of the API can support both old and new interfaces (accepting non-interoperability) but v2.40 and beyond get sorted out. Tim.

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

On 04/12/2013 10:07 PM, 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 and the mechanism value changed 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. 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'm OK with the rename, because I can make that work. On some of my shipping platforms, I may have to hide the rename under an ifdef (ENABLE_CORRECT_PKCS_11_2_40), but I would certainly make using the old structure noisy at compile time (In NSS we do windows and GCC features to tell the compiler to warn the user that they are using deprecated symbols. In GCC 4.5 or later you can actually tell the compiler what the issue is: typedef CK_MECHANISM_TYPE _CKM_MY_BAD_MECH __attribute__ ((deprecated ("CKM_MY_BAD_MECH is not safe use CKM_MY_GOOD_MECH instead, or turn on ENABLE_CORRECT_PKCS_11_2_40")); #define CKM_MY_BAD_MECH ((_CKM_MY_BAD_MECH)0x01D) Though our actual code handles several cases: #if defined(__GNUC__) && (__GNUC__ > 3) #if defined(__GNUC__ == 4) && (__GNUC_MINOR__ < 5) typedef CK_MECHANISM_TYPE _CKM_MY_BAD_MECH __attribute__ ((deprecated ("CKM_MY_BAD_MECH is not safe use CKM_MY_GOOD_MECH instead, or turn on ENABLE_CORRECT_PKCS_11_2_40")); # else typedef CK_MECHANISM_TYPE _CKM_MY_BAD_MECH __attribute__ ((deprecated)); #endif #define CKM_MY_BAD_MECH ((_CKM_MY_BAD_MECH)0x01D) #else #ifdef _WIN32 #pragma deprecated(CKM_MY_BAD_MECH) #endif #define CKM_MY_BAD_MECH 0x01D #endif 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. 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. So a producer of the API can support both old and new interfaces (accepting non-interoperability) but v2.40 and beyond get sorted out. It's obviously not just a recompile to get the correct behavior, some implementations, like mine, would also have to change they way it deals with the parameter, but the compiler would be nice and tell the implementer what is wrong in these cases, so even then they get sorted. Anyway I'm OK with this proposal. bob 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 Attachment: smime.p7s Description: S/MIME Cryptographic Signature

I describe a solution that I think Valerie alluded to that would work for all platforms as far as covering the difference between Well ... which is it? It should be either: (1) CK_ULONG ulPasswordLen; or (2) CK_ULONG_PTR pulPasswordLen; On all operating systems the first page of the process's address space is protected, so that the addresses in the range of 0 - 512 are always illegal and cannot be valid pointers. Notice that a password length fits into this range. This can be used to distinguish between these cases. Let's say we are, the library, are trying to identify which interpretation for the value P the caller is using: the (1) or (2). In terms of C language, when the P is cast to the numeric value of type size_t (that is guaranteed to accommodate a pointer void *) whether P is a ULONG or ULONG_PTR, denoted here as (size_t)P, it follows that    if (size_t)P < 512  => client uses case (1)    else => client uses case (2). Most compilers contain a special symbol that identifies the beginning of the address space of the process, i.e. this or my process address space. For example, the tests above may be able to use __bss_start on GCC. In general, we need to use the symbol that corresponds to the process that loads the library (and not the one corresponding to the PKCS#11 library). Thus, I believe that it's technically possible to write a PKCS#11 library that will inter-operate with a client, whether it's doing (1) or (2).

On 18/04/2013 7:40 AM, Andrey Jivsov wrote: > On all operating systems the first page of the process's address space is protected, > so that the addresses in the range of 0 - 512 are always illegal and cannot be valid pointers. That is an incorrect assumption. On most operating systems that is true - but it is not true on all. It may be true for a sufficiently wide range for it to be a reasonable strategy for implementations (producers) that wish to implement that approach but a consumer of PKCS11 has no idea as to whether or not this behaviour is supported. All three behaviours are in implementations which are deployed. It needs to be fixed as there is no reasonable work around. > Thus, I believe that it's technically possible to write a PKCS#11 library that will inter-operate with a client, whether it's doing (1) or (2). On many operating systems an implementation can work around the issue and support clients doing (1) or (2) but not on all. Tim.

On 04/17/2013 03:03 PM, Tim Hudson wrote: On 18/04/2013 7:40 AM, Andrey Jivsov wrote: On all operating systems the first page of the process's address space is protected, so that the addresses in the range of 0 - 512 are always illegal and cannot be valid pointers. That is an incorrect assumption. On most operating systems that is true - but it is not true on all. It may be true for a sufficiently wide range for it to be a reasonable strategy for implementations (producers) that wish to implement that approach but a consumer of PKCS11 has no idea as to whether or not this behaviour is supported. All three behaviours are in implementations which are deployed. The definition of NULL in the C99 language standard defines NULL to be equal the numeric value 0. The access to 0+small_value is a common incident as a result of access to a field in a structure through a pointer that is NULL. It would be odd to design an operating system in a way that allows struct S{ int a; int b; }; struct S *ps = NULL; ps->b = 1; // <== is not an access violation It needs to be fixed as there is no reasonable work around. But this is not the exact issue here. We don't depend on the "trap". All we need is that the address of ps->b, the invalid reference, is in the range 0...512. AFAIK, there is no concrete operating system where my method cannot be tweaked to work due to NULL == 0. I am not arguing whether the issue needs to be fixed. There is a concern with the lifecycle of already deployed implementations, though. The fix I proposed can be implemented ASAP in the next "patch"; I can't see how it can hurt. However, it makes the documentation bug less severe. Thus, I believe that it's technically possible to write a PKCS#11 library that will inter-operate with a client, whether it's doing (1) or (2). On many operating systems an implementation can work around the issue and support clients doing (1) or (2) but not on all. 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

On 18/04/2013 10:09 AM, Andrey Jivsov wrote: > The definition of NULL in the C99 language standard defines NULL to be > equal the numeric value 0. And that doesn't help - what you are looking for is that a pointer value cannot have the value 0 - and C99 does not define that - the pointer passed incorrectly in ulPasswordLen can be zero and can still be valid. Re-reading C99 6.3.2.2 should make that clearer (although that is an unusual use of the word 'clearer'). However this is diverging from the main topic ... Tim.

On 04/17/2013 06:28 PM, Tim Hudson wrote: On 18/04/2013 10:09 AM, Andrey Jivsov wrote: The definition of NULL in the C99 language standard defines NULL to be equal the numeric value 0. And that doesn't help - what you are looking for is that a pointer value cannot have the value 0 - and C99 does not define that - the pointer I have difficulty locating the standard, but the interpretations of the C standard are abundant to at least strongly suggest to use NULL==0. http://c-faq.com/null/ 5.5 talks about defining NULL to 0 even on machines that use non-zero bit patters to represent the NULL pointer. passed incorrectly in ulPasswordLen can be zero and can still be valid. It's likely that that these systems will not have PKCS#11 libraries running on them. Re-reading C99 6.3.2.2 should make that clearer (although that is an unusual use of the word 'clearer'). However this is diverging from the main topic ... 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