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

[Michael StJohns <msj@nthpermutation.com>]

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.

Can you give chapter and paragraph for other uses please? I looked long 
and hard - went back and looked for all uses of CK_LONG for example, and 
couldn't find any others.


> ... snip
>
> > In line with Peter's suggestion, three new constants are defined:
> >
> >    CKA_INVALID
> >    CKM_INVALID
> >    CK_INVALID_LENGTH
> In addition to their uses in the document. CKA_INVALID and CKM_INVALID
> are useful when writing code. Many (most ?) of us have defined them.
> This is similar to CK_INVALID_HANDLE which is not used in the document.

Sort of - but:

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

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.

Mike




> Cheers,
>
> Stef