[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: Proposal: New CKA_DESTROYABLE attribute
On 13/06/2013 5:40 AM, Stef Walter wrote: > On 12.06.2013 21:35, Tim Hudson wrote: >> On 13/06/2013 5:23 AM, Stef Walter wrote: >>> On 12.06.2013 21:22, Tim Hudson wrote: >>>>> 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 >>>> Absolutely definitely not something I would suggest makes sense. >>>> If we see the need to have a separate name for an error code then it SHALL be a separate value. >>>> Aliases for error codes is not a sensible path IMHO. >>> This is deprecating the CKA_COPY_PROHIBITED because it was part of >>> PKCS#11 v2.30. There's no need for separate error codes. >> That isn't "deprecation" ... any existing example should continue to >> work - we should not be reusing codes (the space for codes is not >> something where we are under sufficient resource constraints that we >> need to carefully monitor each addition). That applies to all the use of >> codes (attribute numbers, mechanism numbers, error codes, flags, etc). > So, to clarify ... what are you proposing here? One of the the following? > > a) C_SetAttributeValue and C_DestroyObject should return one error > code when the action is not permitted (ie: CKR_ACTION_PROHIBITED), > and C_CopyObject should return another (ie: CKR_COPY_PROHIBITED). > > b) C_SetAttributeValue, C_DestroyObject and C_CopyObject should each > return different error codes when the action is not permitted. > > c) something else entirely... If you want to change the error return handling to use a new common error code then do so - but leave the current one alone. Do not introduce aliases for error code values. The comment has nothing to do with its usage - it has to do with re-using values - that should not be done. Make the returns whatever you like - the same, different, something new - just do not reuse values for different error codes. If you have decided you don't like the error code name when wanting to reuse it then you need to introduce a new error code and change the other usages across to working with it noting that returning either the old or the new error code should be expected where it is already defined. Alternatively we can always consider v2.30 to be non-deployed (ignoring the one stated usage by ChrisZ) and use v2.20 as the baseline and assume everything in v2.30 is up for arbitrary change. Tim.