pkcs11 — archive

[Andrey Jivsov]

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.