On 14.01.2011 20:09, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 18:50 +0100, Viktor TARASOV wrote: >> 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. > That's your personal interpretation (see below).
OK, let us read the following lines in PKCS#15 v1.1 ch 6.8.2: "A pin, which is not “local,” is considered “global”. A local PIN may only be used to protect data within a given application." So, it's quite natural for the pkcs15 framework to have access to the path to 'given application' . (There is no sense to have visibility of the local PIN larger then 'given application', and technically, it means that the local PIN is defined in DF (or equivalent) of this application .) So, I propose to include the path (AID) of the 'given application' into the sc_pkcs15_pin_info . For the 'local' PINs with 'path' it's naturally here. For the 'local' PINs without 'path' I propose to derive it from the pkcs15 context. Well, if you don't like to see the 'given application' path melted with the sc_pkcs15_pin_info::path, we can introduce special member . In any case, demand to have the path to the 'given application' in the sc_pkcs15_pin_info to be used by 'local' PINs seems for me righteous. >> 2. Have you seen such a card ? Can you post here it's AODF ? Do you have some real card to illustrate your assumptions, or all this is your considerations about 'how it should be done' ? >> 3. Finally, if no path required, selection of some path will not a effect >> it's verification. > As stated before, "SELECT BY NAME" has very special semantics on Java > Cards and is completely different from "just select another DF". > Therefore there will be harm if used carelessly. Frankly -- I'm bewildered. 1. Particularity of the 'SELECT' command have nothing to do at the pkcs15 level . sc_select_file(), used by pkcs15 level, make abstraction of the all particularities of 'SELECT' command. These particularities (if they are) are implemented by the card driver and hidden behind the common API. 2. Please, can you enlighten us about the 'very special semantics on Java Cards'? Let us look into the GP specification v2.2 ch 11.9.2 'Select command' 'Command message'. We see exactly the same particular case of selection by 'DF NAME' as it defined in ISO/IEC 7816-4 ch 7.1.1 . Roughly it looks like 00 A4 04 00 00/02 L<aid> <AID>. Oberthur is the JavaCard. There is a command to select the 'GP CardManager' 00 A4 04 0C 07 A0 00 00 00 03 00 00 there is the one to select 'AuthentIC' application: 00 A4 04 00 10 A0 00 00 00 77 01 03 03 00 00 00 F1 00 00 00 02 What is there so special? 2.1 When describing the 'very special semantics', can you show the details of how selection of 'given application' will effect the process of verification, and after. Please, give us the detailed scenario of this effect. > So, please take the specification as is: > > "If not present, a card-holder verification must always be possible to > perform without a prior `SELECT' operation." Thanks, I will take. Path to the 'given application' in the pin_info of the local PINs is sufficient. > 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
