pkcs11 — archive

[Michael StJohns]

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