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

["Cohen, Doron" <Doron.Cohen@safenet-inc.com>]

+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.