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? > 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...). >>> 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? >>> 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... > So, waiting to hear from you soon. Working on macros just now :) BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
