Hello Andre, On 15.01.2011 16:52, Andre Zepezauer wrote: > Hello Viktor, > > I know very well that my spelling isn't perfect but I have not expected > that the term "very special semantics" could be misunderstood. My spelling is worse. But this term, that you were using more then once, was so mysterious, so enigmatic. At last you've gave some indication.
> To get an > insight of the subject I was talking about please have a look at the > document attached to this mail: "Runtime Environment Specification". > > There you can find the semantics of the SELECT command defined for Java > Cards. Read section "3 Java Card Applet Lifetime" especially 3.2 and > 3.4. Hopefully the following becomes more clear. Unfortunately not. I found nothing that can be related to the main topic. To resume the main topic: PKCS#15, when describing 'local' PINs, uses the term 'given application'. The sense of existence of the 'local' PIN is to protect data within this application. Opensc pkcs15 framework should have the complete description of the PIN usage. That's why the path to 'given application' is mandatory for the 'local' PINs and has to be present in sc_pkcs15_pin_info data type . If local PINs have no 'path' defined in PinAttributes.path, I propose to derive it from the pkcs#15 context . It comes from itself that selection of the 'given application' has to precede the access to the protected data within it. In any case it should not effect the PIN verification and further functioning . (It's true also because technically the 'local' PIN is created inside this application .) And, in spite of my multiple demands, I have not seen explication of how technically it can have an effect . Your reference to the ticket 252 do not brings more. I don't see how it can be related to the main topic. For me this ticket is about some on-card object protected by obscure PIN that is not present in AODF of the card and that's the reason of 'erase' failure. If you see more, you would have to expose more detailed explication. I stop here, thanks. Kind wishes, Viktor. >>>> BTW care must be take with re-selecting an applet in Java Cards, because >>>> it may invalidate all previously verified PINs. >>> The AIDs of the applets of your Java Card, are they present in some EF.DIR ? >>> Can its be discovered by the procedure previewed by PKCS#15 ? >> You only need to have a default applet that can handle "SELECT 2F00" and >> "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY >> NAME", which is handled by the runtime environment and switches form one >> applet to another. Now you can proceed with 5031 and 5032. >> >> The whole process is nearly transparent. There are only two issues I >> encountered so far: >> * there is no MF per default, but it could be simulated by the applets >> * "SELECT BY NAME" is handled by the Java RE which imposes it's own >> semantics for that command > >>>> 2. Have you seen such a card ? Can you post here it's AODF ? >> Do you have some real card to illustrate your assumptions, or all this >> is your considerations about 'how it should be done' ? > Have a look at [1]. There you will find an example. > >>>> 3. Finally, if no path required, selection of some path will not a effect >>>> it's verification. >>> As stated before, "SELECT BY NAME" has very special semantics on Java >>> Cards and is completely different from "just select another DF". >>> Therefore there will be harm if used carelessly. > Any questions remaining? > > [1] http://www.opensc-project.org/opensc/ticket/252 -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
