Le 28/04/2011 23:11, NdK a écrit : > On 28/04/2011 20:23, Viktor TARASOV wrote: >>> Maybe I could try to write a patch to support $AUTH (or something more >>> generic, see below) for this purpose? >> Yes you can. > Ok. On TODO. > >> You have a reason, probably we'll need to introduce a new auth method. >> The one that could be overwritten with '--auth-id' and used to define access >> for the operations with objects/object-data-files. >> I don't think that it can be more general. >> It has to be used only for the operations for which the access could be >> described in PKCS#15 xxDFs -- with authId, accessControlRules, ... > I'd go for a new parameter, then. Too bad -D is already taken. Falling > back to --define MACRO=value . Or maybe -m/--macro MACRO=value? > >> 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. >> and pkcs15init can (in theory) address the card profile to find out the >> access condition for DFs or xxDF files. > 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. >> It will expect the $PIN value that has been used at the >> creation(initialization) time. > Why? Let's imagine, 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. >> Needs more reflexion. > Yup. Before starting to code, it's better to clarify all aspects. > Just popping up: CREATE acl, IIUC, must be set on the PARENT DF, not on > the EF (that doesn't exist yet...). > >>> $PIN is ambiguous... >> $PIN should be read as $USERPIN > That makes sense only in onepin option or when just PIN and SOPIN exists. That's how it actually translated into the PKCS15INIT PIN types. >>> Even better, something like >>> CRYPTO=$AUTH:$SOPIN:NONE > Handling of this syntax will be in another patch :) > >> Actually, when using pkcs15-init, one needs to choose the '--auth-id' >> corresponding exactly to the ACLs settings in the profile . >> 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... So, waiting to hear from you soon. > BYtE, > Diego. Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
