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. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
