pkcs11 — archive

[Valerie Fenwick]

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.