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