OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: CKA_GLOBAL and uniqueness


On 7/3/2013 12:23 PM, Stef Walter wrote:
Hi Mike,

Apologies for not writing this earlier...

In general I like the concept of being able to tag objects with the
CKA_GLOBAL attribute.

However the part about making sure the objects are unique and
identifiable (via CKA_OBJECT_ID and CKA_CLASS) are less obvious,
especially for this point version of the PKCS#11 spec.

Have you thought about it in the context of a more general object
uniqueness solution?

This isn't an object uniqueness thing per se - see below.
I think that we'll want to have discussions about a
unique/static handle/identifier in the 3.0 spec, and my concern is that
there would be two different solutions.

I think that's  probably orthogonal to this.

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]