Le 29/04/2011 20:49, NdK a écrit :
> On 29/04/2011 15:35, Viktor TARASOV wrote
>> ID '02' will silently go into the authId of a new PKCS#15 object. Nothing
>> more.
> So creating a mismatch between what PKCS#15 knows aout that object and
> what card mandates... And we end up having to look at (possibly out-of
> sync) profiles.
There is an impression that the same thing is repeated for the third or more
times.
So, I venture to resume:
- actually the 'auth-id' argument of the 'pkcs15-init' tool is used as:
-- the ID of a new 'PIN' PKCS#15 Authentication object to be created;
-- the ID of PKCS#15 Auth object that has to protect the usage of a new object
(created with 'pkcs15-init').
In this case the value of 'auth-id' is stored as the PKCS#15 object's
CommonObjectAttributes.authId attribute.
- actually the access conditions (ACL) for a new file/objects are thoroughly
defined in the card profile(s).
- actually, when creating new object with protected usage (using
'pkcs15-init'), the 'auth-id' argument is mandatory.
'Auth-id' argument can have only one possible value: the ID of PKCS#15 Auth
Object for which the value of PinAttributes.pinReference attribute is equal to
the
pin reference indicated by the 'usage' ACLs.
Brief, 'auth-id' has to correspond to the ACLs settings from the card profile.
- this situation is considered as: 'not friendly'(VT), 'dangerous and
error-prone' (NdK), 'possibly out-of sync' (NdK);
- 'auth-id' argument should have a possibility to overwrite, in somewhat
manner, the profile settings for a new object's ACLs.
- there are the volunteers to propose an appropriate solution.
Kind wishes
Viktor.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
