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 ? Our card starts from EF.DIR. Everything that is above this file is out of PKCS#15 context. > > Regards > Andre Kind wishes, Viktor. -- 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
