OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] CK_ULONG considered harmful? -- current summary


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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]