Re: [pkcs11] Define constants for (CK_ULONG)-1

[Stef Walter <stefw@redhat.com>]

On 13.05.2013 16:46, Michael StJohns wrote:
> On 5/13/2013 12:38 AM, Stef Walter wrote:
>> On 11.05.2013 00:30, Michael StJohns wrote:
>>> On 5/10/2013 8:31 AM, Stef Walter wrote:
>>> As discussed earlier on the mailing list, following are the
>>> modifications to the specification to be made in order to define
>>> constants for (CK_ULONG)-1.
>>>
>>>> I went back and took a look at the source documents.  The only place
>>>> that this is used is as a return value of attribute length in
>>>> C_GetAttributeValue to indicate which of the attributes are
>>>> invalid.  (I
>>>> searched for '-1' and the only place I found it - other than SHA-1 and
>>>> length-1 type constructs - was there).
>>>> So how about only CKL_INVALID_ATTRIBUTE = -1;
>> There are several kinds of dashes/hyphens used in a '-1' construct in
>> the document. See my edits below for all appropriate locations of -1
>> cast to CK_ULONG.
> 
> Nope - sorry.
> 
> For mechanism, if there is no valid key gen mechanism you return
> CK_UNAVAILABLE_INFORMATION which is "0", not -1. That's already there
> and has been for 10 years. So the paragraphs on mechanism need to be
> removed. And there's language:
>> The CKA_KEY_GEN_MECHANISM attribute identifies the key generation
>> mechanism used to generate the key material. It contains a valid value
>> only if the
>> CKA_LOCAL attribute has the value CK_TRUE. If CKA_LOCAL has the value
>> CK_FALSE, the value of the attribute is CK_UNAVAILABLE_INFORMATION.
> 
> 
> For an attribute where there is an issue (invalid, sensitive, or longer
> than the provided buffer) the length of the returned attribute gets set
> to -1 in a call to C_GetAttributeValue. AFAICT that is the only place in
> the document where (CK_LONG)-1 is used in this manner. So doing a
> 
> #define CK_INVALID_LENGTH -1
> 
> is probably all you need.

Fair enough.

In fact we can actually just refer to CK_UNAVAILABLE_INFORMATION as the
ulLength returned from C_GetAttributeValue.

CK_UNAVAILABLE_INFORMATION is defined as ~0UL which is == (CK_ULONG)-1

The term 'unavailable information' actually represent what's going in
C_GetAttributeValue when returning a length of -1 quite well.

I had included CKA_INVALID and CKM_INVALID as suggested by Peter, but
I'm fine with dropping them.

>> Valid object handles in Cryptoki always have nonzero values. For
>> developers’
>> convenience, Cryptoki defines the following symbolic value:
>> CK_INVALID_HANDLE
> 
> Which is an alias for "0", and which will never conflict with any valid
> handle.
> 
> Similarly, CK_UNAVAILABLE_INFORMATION is an alias for "0" and will never
> conflict with a valid mechanism type.

Not actually a zero value, but your point still stands.

> This isn't available for attributes as CKA_CLASS is 0. But it's unclear
> it's needed in anything but the context of C_GetAttributeValue. You
> can't use 0xFFFFFFFF as that is in the CKA_VENDOR_DEFINED space and some
> vendor may have already used it. Maybe instead 0x7FFFFFFF? Except that
> having the 0x40000000 bit set says this is an array so instead 0x3FFFFFFF?
>
> I probably wouldn't do either.

Yes, too complex and not used in the spec. Let's skip that.

Cheers,

Stef