Re: [pkcs11] Re: CKA_GLOBAL and uniqueness

["Oscar K So Jr." <oscar.so@oracle.com>]

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

Or,

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;

Best,
Oscar

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

---------------------------------------------------------------------
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