[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: CKA_GLOBAL and uniqueness
On 05.07.2013 06:14, Oscar K So Jr. wrote: > On 07/ 4/13 08:17 AM, Stef Walter wrote: >> CKA_GLOBAL is not a boolean, but an enumeration. This means it's hard to >> C_FindObjectsInit() for all global objects. If it were a pair of boolean >> attributes you could search for CKA_GLOBAL = CK_TRUE. > Yeah, I agree with Stef. > But, where do we set these ? > > CKV_TOKEN_GLOBAL > > CKV_COLLECTION_GLOBAL > > CKV_IMPLEMENTATION_GLOBAL > > CKV_CLIENT_GLOBAL Well you would have a second attribute for these. CKA_GLOBAL_TYPE or something like that. > Michael actually meant that CKA_GLOBAL can be compare as a boolean value > like.... > > Boolean Value = (CKA_GLOBAL == CKV_NOT_GLOBAL) ? CK_FALSE : CK_TRUE; Yes, but then you can only search for equality for CKV_NOT_GLOBAL. You can't search for inequality. In PKCS#11 we can only do equality-match, byte-exact, and-operator, matches. Although this feels limiting, it makes for comprehensibleb implementions of the find logic of a PKCS#11 module (for the alternative see CSSM/CDSA matching logic). But this fact drives the way attributes are chosen. So you can't do a C_FindObjectsInit() for this condition: CKA_GLOBAL != CKV_NOT_GLOBAL But you can do it for something like: CKA_GLOBAL = CK_FALSE So that's why I was suggesting splitting this up. That's why the flags (think all the CKA_ENCRYPT, CKA_DECRYPT and so on) are split up into individual boolean attributes. That's also why every single attribute has a default value (even if that default is empty). I think that the proposal needs more work, although it has merit. Apologies to Mike for not raising these issues earlier :( Cheers, Stef
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]