[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: Proposal: New CKA_DESTROYABLE attribute
On 12.06.2013 19:45, Michael StJohns wrote: > On 6/12/2013 1:15 PM, Stef Walter wrote: >>> Wouldn't you return CKR_ATTRIBUTE_READ_ONLY in this case? >> Yes, perhaps. It is a misleading error code though. There is a semantic >> difference between an object that is not modifiable, and attributes that >> are read-only on an object. > > Fair comment. I think I'm agnostic on adding a new code - either way > works. > >> >> Even if we don't change this, we should document CKR_ATTRIBUTE_READ_ONLY >> as the error code to return in the case of CKA_MODIFIABLE = CK_FALSE. >> Currently it's left as an exercise to the reader. > > If you add a new code or want to add this caveat, it probably needs to > go into section 7.1.2. If you add a new code, we'll need text for 8.1.6 > as well as an updated list of error codes for C_CopyObject. > > [And apparently we forgot to do that for CKR_COPY_PROHIBITED - let me > see if I can propose a paragraph for inclusion] I wonder if we should use the same code in both places, that is: #define CKA_NOT_PERMITTED 0x0000001A #define CKA_COPY_PROHIBITED CKR_NOT_PERMITTED And deprecate CKR_COPY_PROHIBITED ... If it has already been part of a spec revision. It's not in the latest headers. So may just be replaceable. Anyway, the error code denotes that the primary action to be taken by the called function (C_SetAttributeValue, C_CopyObject, C_DestroyObject) is not permitted due to a policy flag (ie: CKA_MODIFIABLE, CKA_COPYABLE, and CKA_DESTROYABLE respectively). Its Section 8.1.6 blurb might look like: CKR_NOT_PERMITTED: This value can only be returned by C_CopyObject, C_SetAttributeValue and C_DestroyObject. It denotes that the action may not be taken, either because of underlying policy restrictions on the token, or because the object has the the relevant CKA_COPYABLE, CKA_MODIFIABLE or CKA_DESTROYABLE policy attribute set to CK_FALSE. If this seems like a good approach, I'd be happy to dress this up into proposal form. Cheers, Stef
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]