Le 29/04/2011 10:38, NdK a écrit : > Il 29/04/2011 09:20, Viktor TARASOV ha scritto: > >>>> We cannot replace $PIN macro with the one that can be modified by >>>> '--auth-id'. >>>> $PIN macro can be used to protect, for ex. the xxDF files itself, >>> Well, I don't see why it shouldn't work :) >> When $PIN translation can change from one init command to another, >> and when $PIN macro is largely used in the card profiles -- one need to be >> careful. > Surely profiles have to be checked. > >>> Urgh! That's not good. :( Access conditions for existing objects should >>> only be read from card... Profile should only be used for new objects... >> Agree, but not every card always returns all necessary information. >> The missing part can be looked for in the card profiles. > Uhm... Doesn't standards mandate that, for example, 3F00 must always be > readable, 4402 contains auth info, etc?
Please, precise what standards are you talking about? From your point of view, where the UPDATE access to 4402 and friends should be defined ? >> some DF have $PIN in its profile settings. In the first init command it was >> created with certain $PIN value translated to its ACLs . >> In the next init command pkcs15init may ask profile to retrieve the ACL of >> this DF and obtain the authorization for some operation . >> So, the $PIN translation has to be the same in the both cases. > Imagine that a card gets initialized on a system where profile has been > customized to ask SOPIN to create keys, then an user tries to add keys > on another machine, where profile says $PIN is to be asked. The result > might be a locked SOPIN, since interface asks for user pin but card > requires sopin... (might be what happened to me...). Really upset for your SOPIN, but I do not completely follow . 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 user is asked for the $PIN (User PIN) the prompt should show an appropriate (more or less) label. The same for SOPIN. 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. If it's not like that, get us look at the extended logs or the detailed description of your actions. >> 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 ? Difficulty to deduce the auth-id from the real ACLs for the 'usefull' object operations ? ... If you see how to improve it -- heartily welcome. >>>> Otherwise the PKCS#15 description will not correspond to the real ACLs . >>>> It's not quite friendly . >>> It seems quite dangerous and error-prone, to me... > 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. >> So, waiting to hear from you soon. > Working on macros just now :) > > BYtE, > Diego. Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
