fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

[Valerie Anne Fenwick <valerie.fenwick@oracle.com>]

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

-------- Original Message --------
Subject: CKM_PKCS5_PBKD2_PARAMS struct: password length
Date: Wed, 03 Apr 2013 14:26:08 -0700
From: Dina Kurktchi <dina.kurktchi@oracle.com>
To: pkcs11@lists.oasis-open.org

Hi all,

What appears to be have been a typo in the specification resulted
in at least one wrong implementation.

The version of the spec I've been looking at is the Draft v2.30,
dated Apr 2009, though I'm sure it's been lurking in v2.20 too.

The version of the header files that I think we are using are
based on v2.20 amendment 3.  From our header files:
        #define CRYPTOKI_VERSION_MAJOR 2
        #define CRYPTOKI_VERSION_MINOR 20
        #define CRYPTOKI_VERSION_AMENDMENT 3

Section 6.22.3, the description of structure CK_PKCS5_PBKD2_PARAMS
lists password length as:
        CK_ULONG_PTR ulPasswordLen;

Well ... which is it?   It should be either:
        (1)     CK_ULONG ulPasswordLen;
or
        (2)     CK_ULONG_PTR pulPasswordLen;

The description of each of the structure members that follows seems
to indicate that (1) was meant, as it says:
        ulPasswordLen   length in bytes of the password information

Checking other *_PARAMS, like CK_PBE_PARAMS in section 6.22.2 just
above for example, password length there is indeed CK_ULONG-typed,
not a pointer.

In today's concall, I heard "The" include files (which, and where?)
list this struct member as CK_ULONG-typed.  Our include files list
it as CK_ULONG_PTR-typed, and that is how we implemented it.


Regards,
D.