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: [pkcs11] PKCS#11 Object Uniqueness error codes

Perhaps, we can also set the CKA_ID during key generation where:

CKA_ID = SHA1(symmetric key CKA_VALUE)

CKA_ID = SHA1(modulus) //this is how Mozilla set CKA_ID in Firefox/Thunderbird

Hopefully, all CKA_ID(s) generated from the above method are unique.
We can then compare all CKA_ID(s) value to determine when to return:

Speaking of the CKA_LABEL, since there is no uniqueness requirement for CKA_LABEL, the application only shows the CKA_LABEL value to the user, and that "MyAppKey" is very confusing. Some application tries to assign a unique label for CKA_LABEL.


On 07/14/14 06:43 AM, Darren J Moffat wrote:
The current PKCS#11 object system doesn't provide for any uniqueness
requirements and depending on the particular library/slot/token the
application may see different behaviour.

For example assuming we are dealing only with symmetric key objects it
is perfectly possible and allowed by the specification to have multiple
objects that differ only in the key value but otherwise have identical
attributes.  This makes it impossible for an application to know which
one it should be using, eg I have two AES keys of the same length and
other attributes and both have a CKA_LABEL of "MyAppKey", which one is
the one to use ?

In fact in Solaris we have two providers pkcs11_softtoken, pkcs11_kms
that behave quite differently.  The former allows you to create any
number of PKCS#11 token objects using C_GenerateKey() with the same
attributes differing only in value.  The later will return the rather
unhelpful CKR_ARGUMENTS_BAD when attempting to create an object with a
CKA_LABEL attribute if one with that label already exists.  The problem
with that is the application can't really determine if the arguments
were bad or if the keyname they attempted to use already existed.

At the very least I think we need to introduce a new error code
CKR_OBJECT_EXISTS or CKR_KEY_EXISTS for those tokens that do have
requirements they need to enfore.  However it would be better if we
could agree on some uniqueness requirements for classes of keys.

I realise that for some objects the label might not be an ideal primary
key for determining uniqueness, so maybe this is something that does
remain up to each vendor for their libraries/tokens.

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