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 ? Here the 'local PIN' means the PIN for which the 'verified' status is lost when walking from the application DF, where it's defined, onto the MF (or similar level where the 2F00 is) or into the other application, mentioned in 2F00 (EF.DIR)? -- 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
