Re: [pkcs11] Re: Proposal: New CKA_DESTROYABLE attribute

[Tim Hudson <tjh@cryptsoft.com>]

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.