pkcs11 — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
New attribute: CKA_ATTRIBUTES
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]