Le 29/04/2011 14:20, NdK a écrit : > Il 29/04/2011 13:49, Viktor TARASOV ha scritto >> Please, precise what standards are you talking about? > PKCS#15, ISO7816 and every applicable one. >> From your point of view, where the UPDATE access to 4402 and friends >> should be defined ? > Since UPDATE refers to an existing object, it belongs to that object.
4402 is not an object that can be described by PKCS#15, it's the PKCS#15 itself -- AODF descriptor of the PKCS#15 structure. The only place where its UPDATE access is defined (beside the file's FCP) is the profile. > But CREATE, being referred to a non-existing object, should belong to > container (parent) object. Once more, parent is not an PKCS#15 object. If 'SELECT' parent do not return FCP data, there is no way to get the real ACLs. The only hope is that the profile settings correspond to the real (hidden) ACLs. >> For me this discussion is about coherence in usage of the OpenSC tools, of >> the OpenSC libraries and profiles . >> Profiles are not to be changed inside the card lifecycle . > If a profile is used only when creating objects, then there's no need to > have it at all when just using a card (w/o creating new objects on it). > But it seems that the need to change profiles is quite common, since > "options" have been included. > It's not "good" that problems arise if I create a card using > pkcs15+onepin and a user creates a key using just pkcs15 profile! It's up to you to educate your users. Once more, actually, the pkcs15init is designed to make possible the administration of the cards (probably absolutely obsolete cards) that do not always return all necessary information. Missing information for such a cards is looked for in the profiles. It presumes some 'stability' of the profiles. Probably these precautions is not more (was never) valid. Pkcs15init has to be reviewed/retested to see if these precautions are still necessary. >> If user is asked for the $PIN (User PIN) the prompt should show an >> appropriate (more or less) label. >> The same for SOPIN. > So, if I specified -a 02 to -G, I should get prompted for "label of pin > with ID = 02" (in my case CHV2, that I use as "user auth", while CHV1 is > "card auth" to limit access to creation and deletion of objects on card). No, you will be prompted for the PIN that was deduced from the FCP of the parent that has been selected at the moment just before generation . If 'SELECT' of your parent do not returns FCP, then your profile will be asked to create virtual instance of you parent and this one will certainly have the needed ACL. ID '02' will silently go into the authId of a new PKCS#15 object. Nothing more. Then, when you will try to use this generated key, for ex. to make a signature, your PIN value argument will be used in the VERIFY command with the 02 as pin-reference . > Till now, the only way I could find to obtain that is to change the > profile before generating the key (and making sure that profile-given > PIN and -a -given PIN are actually the same object, or PKCS#15 data and > object-acl gets out of sync). > >> Afaiu, your card can return all necessary information to authorize some >> operation. >> Your profile 'should not be' asked for the ACLs of an existing file/objects. > Then it's OK. >> If it's not like that, get us look at the extended logs or the detailed >> description of your actions. > Didn't dig this deep into card-specific code. It's going about the logs from your 'suspicious' session where SOPIN was blocked. >>>> Actually, when using pkcs15-init, one needs to choose the '--auth-id' >>>> corresponding exactly to the ACLs settings in the profile . >>> Forgot to ask: then why allow the user to specify it? >> Historical reasons ? > This should not be a compelling reason. Here I do not compel, but answer your question. I compel that we should make an attention for the cards that are not capable to return all necessary information. > If my vars patch works, it > becomes quite easy to convert "--insecure" to "-d auth=NONE" and "-a 01" > to "-d auth=CHV1". >> Difficulty to deduce the auth-id from the real ACLs for the 'usefull' object >> operations ? > I have to look at how "real ACLs" look like. >> If you see how to improve it -- heartily welcome. > I think the vars patch I'm preparing could be useful for that... > >>> As I see it, profiles should only be used for creation of objects. All >>> the infos needed later should be sccessible throught PKCS#15 (or other >>> standards) descriptions, or even set by card drivers... >> I'm absolutely agree -- 'should be' . >> But, for a while have take into account that not all cards can. > Those, then, should be "emulated" by a *fixed* profile. ... > BYtE, > Diego. Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
