pkcs11 — archive

[Michael StJohns]

On 10/25/2013 1:16 PM, Chris Zimman wrote: Hi Mike Yes, we manage the users through an external mechanism. As you're aware, PKCS11 doesn't really have the notion of add/delete/change privs in the existing API. I wanted to preserve compatability. OK. I may try and define a CKO_USER_CREDENTIALS object - I think that may work for doing things similar to what you do. The structure is passed as a void * to the PIN argument and sizeof(CK_EXTENDED_LOGIN) for the length argument. That's what I thought. Unfortunately, that won't work well with the Java PKCS11 implementation due to strong typing. Void pointers are to be avoided. :-) In my implementation, there is a table/attribute driven state machine that allows you to define somewhat arbitrary rules for each type of C_* operation via callbacks. typedef struct { CK_ATTRIBUTE_TYPE attr_type; CK_BBOOL token_impl_specific; CK_RV (*set)(CK_ATTRIBUTE *); CK_RV (*validate)(CK_ATTRIBUTE *); } bpkcs11_vendor_attr_list_item; An example of how this is used looks something like this: static bpkcs11_vendor_attr_list_item bpkcs11_vendor_attrs[] = { { CKA_OWNER_UUID, CK_TRUE, set_uuid, validate_uuid }, { CKA_ALLOWED_USE_TIME_START, CK_TRUE, set_use_time_start, validate_use_time_start }, { CKA_ALLOWED_USE_TIME_STOP, CK_TRUE, set_use_time_stop validate_use_time_stop }, { CKA_EXPORT_SHARE_REQUIRED, CK_TRUE, set_share_exp_req, validate_share_exp_req }, { CKA_EXPORT_SHARE_REQUIRED_NUM, CK_TRUE, set_share_exp_req_num, validate_share_exp_req_num }, }; The attributes are for things like checking an object owner via UUID, checking the time that an object is legal to use, or that to export an object requires a threshold. --Chris