On Fri, 2011-01-14 at 18:50 +0100, Viktor TARASOV wrote: > On 14.01.2011 18:36, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 18:31 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 17:53, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote: > >>>> On 14.01.2011 16:51, Andre Zepezauer wrote: > >>>>> On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: > >>>>>> On 14.01.2011 15:17, Andre Zepezauer wrote: > >>>>>>> On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: > >>>>>>>> On 14.01.2011 13:37, Andre Zepezauer wrote: > >>>>>>>>> On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > >>>>>>>>>> Hello Andre, > >>>>>>>>>> > >>>>>>>>>> On 14.01.2011 04:24, Andre Zepezauer wrote: > >>>>>>>>>>> please have a look at PKCS#15 "6.8.2 Pin objects" for the > >>>>>>>>>>> definition of > >>>>>>>>>>> local and global PIN objects. There is no mention of storage > >>>>>>>>>>> location. > >>>>>>>>>> There is mention of 'path'. > >>>>>>>>>> The difference between 'global' and 'local' is that the first one > >>>>>>>>>> can be verified from any location on the card, > >>>>>>>>>> the second one is 'visible' only from somewhere under the DF (or > >>>>>>>>>> application) where it's defined. > >>>>>>>>>> > >>>>>>>>>> So, we need (or, if you like, it's useful) to have 'path' defined > >>>>>>>>>> for the local PINs, to be able to select it's path before > >>>>>>>>>> verification. > >>>>>>>> My previous assumptions comes from this citation. > >>>>>>>> It seems that I am terribly missing something. Can you give more > >>>>>>>> details? > >>>>>>>> > >>>>>>>> > >>>>>>>>>> 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. > >>>>>>>> That's 'local' PIN. > >>>>>>>> > >>>>>>>>> If not present, a card-holder verification > >>>>>>>>> must always be possible to perform without a prior `SELECT' > >>>>>>>>> operation." > >>>>>>>> That's the global one. > >>>>>>>> > >>>>>>>> > >>>>>>>> So we desperately need the 'path' for the local PINs. So that 'host > >>>>>>>> application' can select the path > >>>>>>>> 'before doing a PIN operation'. > >>>>>>>> You probably know another way to do verification from the random > >>>>>>>> location on the card ? > >>>>>>> Take Java Card with PKI applet as an example. Once the applet is > >>>>>>> selected, it is possible to perform the VERIFY command from every > >>>>>>> location within that applet. That's 'local' PIN too. Because it's only > >>>>>>> valid for that applet but not for the whole card. > >>>>>> OK, let us adjust the terminology. > >>>>>> I am talking about the PKCS#15 card. This card starts from some MF, > >>>>>> where exist EF.DIR, probably EF.ATR, ..., as well as application DFs. > >>>>>> The AID of application DFs are present in the EF.DIR records. > >>>>>> The global PINs are defined at the MF level or above, the local ones > >>>>>> are defined in application DFs. > >>>>>> > >>>>>> In my comprehension to create/use the PKCS#15 objects you don't need > >>>>>> to jump higher then MF, and thus to reset status of 'global' PINs. > >>>>>> You have another vision, examples ? > >>>>>> > >>>>>> > >>>>>>> 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. > >>>> Well, it seems that we are talking about the same thing. > >>>> > >>>> We've gone away from the original item. > >>>> Do you have something against committed proposal to complete the missing > >>>> 'path' for the local PINs when decoding AODF ? > >>> Yes, the patch you have committed is a fix for cards not following > >>> PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current > >>> proposal effects every card not only the broken ones. > >> > >> Explain me please how it effects the other cards. > >> > >> The other 'normal' cards > >> - for the local PINs they have 'local' set in their pinFlags and have > >> the 'path' in pinAttributes; > >> - for the global PIN they have no 'local' in pinFlags and have no path > >> in pinAttributes. > >> > >> > >> There are 'anormal' cards that for the local PINs have flag 'local' in > >> pinFlags, but have no 'path' in pinAttributes. > >> My proposal concerns these ones. > >> > >> > >> Please, give me a detailed description of the PinAttributes that can be > >> effected by this proposal. > > Local PIN with no path required. > > 1. If no path required, it means that it can be verified from every where in > the card -- it's the global PIN.
That's your personal interpretation (see below). > 2. Have you seen such a card ? Can you post here it's AODF ? > > 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. So, please take the specification as is: "If not present, a card-holder verification must always be possible to perform without a prior `SELECT' operation." Regards Andre _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
