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. "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
