Re: [pkcs11] Re: CKA_GLOBAL and uniqueness

[Michael StJohns <msj@nthpermutation.com>]

On 7/4/2013 11:17 AM, Stef Walter wrote:
> 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.

Right - but.  I considered the approach of a boolean attribute plus a 
type attribute, but decided on the current version.  The main reason is 
to prevent things like a vendor providing an object with 
CKA_GlOBAL=FALSE and then the CKA_GLOBAL_TYPE value being some value 
that indicates the object really is global.  It was yet another 
paragraph of "make sure you don't do this" related to inconsistency that 
I wanted to avoid.

For your C_FindObjects etc - the number of distinct global types is 
small - it's not all that hard to iterate through them.  For any given 
type of token, the set should be fixed.  Hmm... think of it this way.  
It might be useful to be able to use C_FindObjects etc to find all the 
keys on a token.  But, you can't in one pass.  You have to look for 
CKA_CLASS=CKO_PRIVATE_KEY, CKO_SECRET_KEY and CKO_PUBLIC_KEY.  We could 
have added a CKA_IS_KEY boolean, but we didn't.

In any event, the general way for finding these things is going to be by 
the CKA_OBJECT_ID - e.g. the client has an application that needs to use 
one specific type of global object.  The definition of that global 
object will give you the CKA_OBJECT_ID and the value of CKA_GLOBAL  and 
CKA_CLASS.   I couldn't actually think of an operational (vs a developer 
playing with it) use case where you needed to be able to scan for all 
the global objects.

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

Right - but CKA_OBJECT_ID was also (previous to this proposal) specified 
to describe the application to be used with such key(s). Again, CKA_WRAP 
and CKA_ALLOWED_MECHANISMS gives you the generic use of the object, 
CKA_OBJECT_ID tells you which application really cares - or which 
application placed the key in the first place.

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

Maybe - but what happens when someone else comes along with another 
application and another key that has similar mechanisms and 
permissions?   It doesn't even work for seal keys.  There are at least 
two different types of seal keys - token and session.  They differ 
mostly by CKA_OBJECT_ID.  There will probably be a third type of seal 
key - again with a different OID.

> In PKCS#11 all objects are fully formed for their class.

I wish that were the case.  It actually isn't in practice.

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

Oh - now I see what you're getting at.  Actually, it doesn't do what you 
say it does.  All objects get a CKA_GLOBAL value (generally with the 
default of CKV_NOT_GLOBAL).  (This is exactly equivalent to adding 
CKA_DESTROYABLE with a default of CK_TRUE to all objects and that's how 
you do it for backwards compatibility)

 Only objects of CKA_GLOBAL != CKV_NOT_GLOBAL get the CKA_OBJECT_ID as 
an added mandatory attribute if they didn't already have it.

> Cheers,
>
> Stef
>
> On 03.07.2013 22:21, Michael StJohns wrote: