pkcs11 — archive

[Michael StJohns]

On 5/28/2013 1:44 PM, Valerie Anne Bubb Fenwick wrote: On 5/28/13 10:34 AM, Chris Zimman wrote: 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 That is my understanding as well. I think to do this really correctly, we should use explicit types, which leaves no room for confusion. But, that's too disruptive for 2.40. Valerie The first issue has been deferred - agreed. The second one came up as an aside to the first one - it is not the same for various reasons. I think it gets deferred as well.