Re: [pkcs11] CK_ULONG considered harmful?

[Michael StJohns <msj@nthpermutation.com>]

On 5/20/2013 5:46 PM, Chris Zimman wrote:
> > I think the right thing to do here is for me to withdraw this comment (unless someone comes up with an actual problem encountered).
> I don't think withdrawing it is necessary -- it's just something that might be better left until 3.0.  Having non-exact specified types is bad, and it can lead to a wide variety of problematic situations.  The most simple example is where a token and interface disagree on the size of a CK_ULONG.  For example, a token that's internally 64 bit and can support 64 and 32 bit clients:  If the 64 bit client creates an object that contains an item with a 64 bit CK_ULONG value inside of it for whatever reason, there's no way for the 32 bit client to understand it since it may contain a value greater than 32 bits.  Both things have been operating legally.  Also, what is a 64 bit client supposed to do if it tries to submit a value to a 32 bit token in a CK_ULONG that exceeds 32 bits?  The token will have to reject it, but there aren't even error codes to handle all the cases.  Granted, most values fit into a 32 bit size, but that's more coincidence vs. good design.

Hmm...

Actually, I don't think this is quite right.

There is the program to pkcs11 driver stuff on the using system.
There is the on-the-wire protocol between the driver and the server on 
the HSM system.
There is the server to underlying HSM implementation - which may or may 
not be PKCS11.

The program to PKCS11 stuff is covered as discussed.

Mapping the on-the-wire protocol can be tricky, but people do it every 
day.  You just need to ensure that you do the translation from the using 
system representation of CK_ULONG to an on-the-wire representation to a 
server representation.   And let's not even talk about how you deal with 
pointers in a network encoding!
I think that the network representation is out of the purview of this 
group mostly.


How about:

"Although the internal representation for a CK_ULONG may be 32 bits or 
longer, by convention, only the least significant 32 bits shall be used 
to represent PKCS11 data values (with the one exception of the ~0UL 
value *sigh*).  This permits a loss-less conversion from a CK_ULONG 32 
bit value to a CK_ULONG 64 bit value and vice versa."

This wouldn't be a change to the headers or anything else, just a 
description of the convention used for assigning values so that 
reasonable choices can be made to do network protocol design (or even VM 
to VM type calls).

Mike