Re: [pkcs11] New attribute: CKA_ATTRIBUTES

[Tim Hudson <tjh@cryptsoft.com>]

Just a quick note - that at least one vendor has this approach as a
vendor extension - although done a little differently than proposed here
- instead of returning a list it is an iterator approach returning each
attribute from C_GetAttributeValue after a C_GetAttributeValue call
using that vendor extension attribute.

The array returning approach seems like a better way to handle this -
and it would be good to see this included if there is wider general
interest.

Tim.

On 30/05/2013 1:48 AM, Michael StJohns wrote:
> I'm getting into a bit of feature creep here, but I've often wished
> for an easier programmatic way to determine which attributes were
> applicable to which object.   Here's one approach.
>
> <text>
>
> #define CKA_ATTRIBUTES   (<toBeAssigned> | CKF_ARRAY_ATTRIBUTE)
>
> Data type is CK_ATTRIBUTE_TYPE_PTR
>
> typedef  *CK_ATTRIBUTE_TYPE CK_ATTRIBUTE_TYPE_PTR;   // Needs to be
> added to CK_ATTRIBUTE_TYPE def
>
> This is a read-only, non-sensitive attribute present on all or none of
> the objects in a token.  If present it contains an array of
> CK_ATTRIBUTE_TYPE representing the complete set of valid attributes of
> that object.  If an attribute may be used for for an object,
> regardless of the purpose or sensitivity of that attribute, it must be
> included in the set for that object.
>
> </text>
>
> It may be that we define two of these, one for all valid attributes,
> and one for attributes actually present.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php