Hi Viktor/all, It seems that in the following commit to the secure-messaging branch - "pkcs11: rewrite pkcs15_create_tokens() -- use static sub-funcs" - the requirement for a private key to have a link to a PIN ID got a bit stricter. In previous versions, it seems that if an object wasn't added by linking to other objects, it was then added in the "add all remaining objects" section. Now, only public objects are added in this way.
This seems right, but has caused a problem in my testing. I am using an IAS/ECC card, and the private key doesn't have an authID parameter in the CommonObjectAttributes - it has this parameter in the accessControlRules. This means that pkcs15_add_object is never run on this key, and it is thus not useable by any applications. Looking at the specs, the card seems correct - it seems that the IAS/ECC specifications do not require an authID parameter in the CommonObjectAttributes (even though 7816-15 does), but specify this parameter to be present in the accessControlRules section (see pg 176/177 of the IAS/ECC v1.0.1 specification). This is also seen in the CEN/TS 15480-2 specs. Thus it seems likely that this could also occur in other cards. The following patch solves this problem for the PKCS11 module. It may need some more thought - do we rather want to apply this at a lower level - e.g. sc_pkcs15_decode_prkdf_entry? I would think not, as this should just represent a decoding of the ASN.1 entry, not an interpretation of it. Let me know what you think. Regards, Will
private-key-auth_id.patch
Description: private-key-auth_id.patch
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
