Re: [pkcs11] Re: CKA_GLOBAL and uniqueness

[Stef Walter <stefw@redhat.com>]

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