RE: [pkcs11] CK_ULONG considered harmful? -- current summary

[Chris Zimman <czimman@bloomberg.com>]

> There are two distinct items here:
>
> 1) Clarifying CK_ULONG (if necessary) for the general case.
>
> -- There appears to be no current issue for the use of the variable length type within the same process space.
> -- There may be some issues for supporting values of this type where there is an intermediate (e.g. network connected) form/protocol. That may suggest locking the type to a > fixed length, or at least constraining the values so that there can always be a loss-less conversion to/from 
> the intermediate form.   That's (special processing) already required 
> for handle-like objects.
>
> 2) Providing support for 64 bit lengths for C_Encrypt, C_Decrypt etc.
>
> -- This is actually a second, and more interesting issue.  CK_ULONG is used as a length type for the various data processing commands (e.g. 
> C_Encrypt, C_Decrypt, C_Digest etc).    If the local typing has this as 
> a 32 bit value, a single call is limited to 4 gig of data.  The work around - as usual, is to break up the chunks into less than 4 gig and call the C_*Update routine.
>
> -- Should the maximum values for CK_ULONG be clarified for the existing routines to be uint32_t.MAX-1?
> -- and/or Should there be additional routines that support a uint64_t type for length?
> -- Or is this a don't care?  (e.g. it's up to the caller to determine whether the HSM supports uint64_t lengths and to use > 4G buffers).

My current understanding is that this is going to be deferred to >= 3.0