On Sun, 2011-01-16 at 11:58 +0100, Viktor TARASOV wrote: > > 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 .
That patch is not required. From PKCS#15 "6.8.2 Pin objects": "PinAttributes.path: Path to the DF in which the PIN resides. The path shall be selected by a host application before doing a PIN operation, in order to enable a suitable authentication context for the PIN operation. If not present, a card-holder verification must always be possible to perform without a prior `SELECT' operation." To me it seems, that you want to fix just another bug for the broken IAS/ECC cards. Why not writing an emulator for them to avoid pollution of generic code with these undocumented hacks? > 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. >>> Local PIN with no path required. >> 2. Have you seen such a card ? Can you post here it's AODF ? > Have a look at [1]. There you will find an example. > 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. [1] http://www.opensc-project.org/opensc/ticket/252 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
