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