Hello NdK (Diego?) A side note: PKCS#15 profiles related parts of OpenSC are quite undocumented and difficult to understand/follow (as you probably have experienced yourself)
If you feel like improving what you read, as you go on, what about updating - pkcs15-profile (should it be renamed to pkcs15.profile?) manual page [1] - CardPersonalization [2] wiki page (or better yet, create a new page for a "writing/modifying a PKCS#15 profile") Cheers, Martin, off to gardening for the weekend. [1] http://www.opensc-project.org/opensc/browser/trunk/doc/tools/pkcs15-profile.xml [2] http://www.opensc-project.org/opensc/wiki/CardPersonalization On Apr 29, 2011, at 15:20 , NdK wrote: > 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. > But CREATE, being referred to a non-existing object, should belong to > container (parent) object. > >> 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! > >> 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). > 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. > >>>> 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. 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. > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
