pkcs11 — archive

[Stef Walter]

Thanks for explaining. Are the CKA_OBJECT_ID values going to be well defined? That is for your seal key use case? What arc are they going to be defined under? But it seems that CKA_GLOBAL proposal breaks from the spec in several respects. Nothing irreparable. 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. 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. > > Mike > > >> >> Cheers, >> >> 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