pkcs11 — archive

[Gil Abel]

> Implementation of this for X.509 certificates would be trivial in > comparison to doing it for public and private keys. Agree, it is indeed different. For certs it requires ASN.1 parsing and for keys, it is device specific, but the library should obviously know how to communicate with its device. For modules that do not have asn.1 parsing capabilities (I've read such concerns about it in this thread), it may be a problem though, the certificate object itself is complex and not a simple SEQUENCE. I would like to ask a clarification question. Is the intend to add an attribute that can be passed to while creating the object and have it retuned while in C_GetAttributeValue? What happens if one passes (in create or set attribute) an attribute with a value that is different from what's being coded in the CKA_OBJECT itself? If the module would return the value coded in CKA_VALUE, then the value pass to C_CreateObject (or C_SetAttributeValue) is actually meaningless, and would never be returned/used. It is true that there are already other attributes today that are "doubly defined", like the subject field, which are a source of incompatibility between different modules. It would be good to solve this inconsistency too, maybe in a next standard version. Gil.