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

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

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.