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?


On 05/21/2013 01:27 PM, Michael StJohns wrote:
On 5/21/2013 3:58 PM, Chris Zimman wrote:
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.
It's not really a problem of wire mapping etc at all -- explain to me how I'm going to get a value that's stored as 64 bit into a 32 bit client.
AFAIK about the only place this is a real issue is with (session |
object ) handle representation.  The rest of the uses of CK_ULONG in
pkcs11 are all values that can be represented without loss in 32 bits.
(I may have missed a mechanism where this isn't the case, but I would be
surprised).

There are 202 lines in pkcs11f.h and pkcs11t.h at ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20 that contain CK_ULONG. Some of them are the lines like

   typedef CK_ULONG          CK_SLOT_ID

which means that the actual number of much greater.

Mandating CK_ULONG to be under 2^32 means that the following functions cannot be called on large buffers.

/* C_Encrypt encrypts single-part data. */
CK_PKCS11_FUNCTION_INFO(C_Encrypt)
#ifdef CK_NEED_ARG_LIST
(
  CK_SESSION_HANDLE hSession,            /* session's handle */
  CK_BYTE_PTR       pData,               /* the plaintext data */
  CK_ULONG          ulDataLen,           /* bytes of plaintext */
  CK_BYTE_PTR       pEncryptedData,      /* gets ciphertext */
  CK_ULONG_PTR      pulEncryptedDataLen  /* gets c-text size */
);
#endif
...

IMO the bigger problem is with lengths. There are a lot of them in these headers that use CK_ULONG.

The handle, on the other hand, is host-specific. HANDLE-types will need special processing for transfer outside of the process space anyway. CK_ULONG is expected to be defined the same way for the in-process use.

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