[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: CKA_GLOBAL and uniqueness
On 07/ 4/13 08:17 AM, Stef Walter wrote:
Yeah, I agree with Stef.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. But, where do we set these ? CKV_TOKEN_GLOBAL CKV_COLLECTION_GLOBAL CKV_IMPLEMENTATION_GLOBAL CKV_CLIENT_GLOBAL Michael actually meant that CKA_GLOBAL can be compare as a boolean value like.... Boolean Value = (CKA_GLOBAL == CKV_NOT_GLOBAL) Best, In the past flag attributes like CK_WRAP have been used together with CKA_ALLOWED_MECHANISMS to identify keys appropriate by a given mechanism. There are some nuances here of course, but having CKA_OBJECT_ID everywhere overlaps with this usage. It seems that you could identify a seal key by doing a search for: * CKA_GLOBAL = CK_TRUE (or whatever appropriate enumeration value) * CKA_ALLOWED_MECHANISMS = CKM_SEAL_KEY (since you can't use it for anything else) * CKA_UNWRAP/CK_WRAP = CK_TRUE It seems the above would remove the need for a well defined OID arc, and also the issue below. In PKCS#11 all objects are fully formed for their class. CKA_GLOBAL changes that rule, by introducing the ability to have CKA_GLOBAL and CKA_OBJECT_ID on any object. One way to fix this is to add a new common storage attribute(s). CKA_GLOBAL would be specified to have a default value. Cheers, Stef On 03.07.2013 22:21, Michael StJohns wrote:In addition, it seems that we add CKA_OBJECT_ID as an attribute that nearly every class can have. Does that mean it's always present (and empty) for all the common storage classes?No. It is always present for global objects (e.g. CKA_GLOBAL not present or == CKV_NOT_GLOBAL), it doesn't affect any other object (unless they already provide support for the attribute). The problem is that you need an extensible way of tagging a global object to associate it with a particular functionality. E.g. there may be many secret global keys, but only one secret global key of token scope that is used for sealing other keys. The OID tells you what the intended purpose is for the object and makes it pretty easy to determine which of possibly many keys is the one you want. This is not about object uniqueness, but about making it easy for to identify objects associated with an application.On the other hand, if we do come up with a different uniqueness solution for 3.0, we could remove the solution applied to CKA_GLOBAL. So can your proposal survive without the last 5 paragraphs? Is the solution dependent on this part?Here's the problem with removing this - consider for example the Seal key. If I can have 2, 3 or more secret seal keys in a particular class (CKV_TOKEN_GLOBAL for example), then I seal a key with the first seal key, when I go to unseal that sealed key, I need to know exactly which key to use - which means I need something like a CKA_UID - which I now have to store with the opaque sealed key blob. I ran through a number of scenarios and I didn't come up with a single one that required multiple different objects using the same OID and same class. If you really need something like this you define an OID arc for the application and the last component of that arc defines a specific instance. E.g. Mike's strange collection of objects: 1.3.6.1.4.1.993939.12.1 - arc, 1.3.6.1.4.1.993939.12.1.23, 23rd object of that arc. This is sort of SNMPish, but seems to be reasonable way of doing things. (And that's how you would handle something like multiple types of CKM_CERTIFY_KEY associated keys and certs). Remember that ALL of the global objects are under the complete and total management of the token vendor - they get to decide which collections of objects they want to support if any. MikeCheers, Stef--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Best, Oscar |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]