Hi Viktor, > -----Original Message----- > From: Viktor Tarasov [mailto:viktor.tara...@gmail.com] > Sent: 07 December 2011 13:08 > > Hello William, > > Le 06/12/2011 11:54, Hunter William a écrit : > > 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. > > > You have a reason -- 'accessControlRules' is more detailed version of > 'authId' and takes precedence if both exist. > We should also update the opensc tools (like pkcs15-crypto) that uses > the authId to get authorization to perform cryptographic operation. >
Ok, yes, I see that - so should we allow the accessControlRules parameter to override the authId? It seems so... I can update the pkcs15-crypt tool. Are there any other places that need updating? I can see that on a login (pkcs15_login), we might expect additional keys to become available, and these must match the auth_id too. > Is it happens for you to have the accessControlRule that protects by > the different 'PIN' objects the IntrenalAuth, Decipher and Sign > operations of the same key ? > Could we assume, that only one 'PIN' type auth.object is present in > 'accessControlRules' of one key ? > It seems to me that both PKCS#11 and the minidriver only support one (user) PIN per card, so this has to be so for these modules to work? However, the specifications support multiple PIN objects, so a card may in theory have different PIN's for different operations. It just isn't clear to me how this would then work? The pkcs15-crypt tool may be able to get it right, but how would you support this for the PKCS#11 module or the minidriver? I'm happy to implement this, but do you (or anyone else) have any suggestions on how to do it properly? Would it be something like: Instead of using p15_obj->auth_id, use the following function: pkcs15_get_auth_id(struct pkcs15_object *obj, unsigned int operation) where operation would be a set of bits checked against the accessMode. It would return the first sc_pkcs15_id that matches any of the operations flagged, first checking the accessrules, and then returning obj->auth_id if none match. This should work fine for pkcs15-crypt, but for framework- pkcs15, it would have to just return the first auth_id it finds with any valid operation, and any others would be ignored. I can't see that the minidriver uses auth_id at all (except to set it where necessary). So, for the minidriver, the key auth_id and the first user PIN *have* to match, or else things just don't work? Cheers, Will _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
