Re: [opensc-devel] r5081
On Sun, 2011-01-16 at 11:58 +0100, Viktor TARASOV wrote: > > There you can find the semantics of the SELECT command defined for Java > > Cards. Read section "3 Java Card Applet Lifetime" especially 3.2 and > > 3.4. Hopefully the following becomes more clear. > > Unfortunately not. I found nothing that can be related to the main topic. > > To resume the main topic: > PKCS#15, when describing 'local' PINs, uses the term 'given application'. > The sense of existence of the 'local' PIN is to protect data within this > application. > Opensc pkcs15 framework should have the complete description of the PIN usage. > That's why the path to 'given application' is mandatory for the 'local' PINs > and has to be present in sc_pkcs15_pin_info data type . > If local PINs have no 'path' defined in PinAttributes.path, I propose to > derive it from the pkcs#15 context . That patch is not required. 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. If not present, a card-holder verification must always be possible to perform without a prior `SELECT' operation." To me it seems, that you want to fix just another bug for the broken IAS/ECC cards. Why not writing an emulator for them to avoid pollution of generic code with these undocumented hacks? > It comes from itself that selection of the 'given application' has to precede > the access to the protected data within it. > In any case it should not effect the PIN verification and further functioning > . > (It's true also because technically the 'local' PIN is created inside this > application .) > And, in spite of my multiple demands, I have not seen explication of how > technically it can have an effect . > > Your reference to the ticket 252 do not brings more. I don't see how it can > be related to the main topic. >>> Local PIN with no path required. >> 2. Have you seen such a card ? Can you post here it's AODF ? > Have a look at [1]. There you will find an example. > For me this ticket is about some on-card object protected by obscure PIN that > is not present in AODF of the card and > that's the reason of 'erase' failure. If you see more, you would have to > expose more detailed explication. > > I stop here, thanks. > > Kind wishes, > Viktor. [1] http://www.opensc-project.org/opensc/ticket/252 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
Hello Andre, On 15.01.2011 16:52, Andre Zepezauer wrote: > Hello Viktor, > > I know very well that my spelling isn't perfect but I have not expected > that the term "very special semantics" could be misunderstood. My spelling is worse. But this term, that you were using more then once, was so mysterious, so enigmatic. At last you've gave some indication. > To get an > insight of the subject I was talking about please have a look at the > document attached to this mail: "Runtime Environment Specification". > > There you can find the semantics of the SELECT command defined for Java > Cards. Read section "3 Java Card Applet Lifetime" especially 3.2 and > 3.4. Hopefully the following becomes more clear. Unfortunately not. I found nothing that can be related to the main topic. To resume the main topic: PKCS#15, when describing 'local' PINs, uses the term 'given application'. The sense of existence of the 'local' PIN is to protect data within this application. Opensc pkcs15 framework should have the complete description of the PIN usage. That's why the path to 'given application' is mandatory for the 'local' PINs and has to be present in sc_pkcs15_pin_info data type . If local PINs have no 'path' defined in PinAttributes.path, I propose to derive it from the pkcs#15 context . It comes from itself that selection of the 'given application' has to precede the access to the protected data within it. In any case it should not effect the PIN verification and further functioning . (It's true also because technically the 'local' PIN is created inside this application .) And, in spite of my multiple demands, I have not seen explication of how technically it can have an effect . Your reference to the ticket 252 do not brings more. I don't see how it can be related to the main topic. For me this ticket is about some on-card object protected by obscure PIN that is not present in AODF of the card and that's the reason of 'erase' failure. If you see more, you would have to expose more detailed explication. I stop here, thanks. Kind wishes, Viktor. 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. >> >> The whole process is nearly transparent. There are only two issues I >> encountered so far: >> * there is no MF per default, but it could be simulated by the applets >> * "SELECT BY NAME" is handled by the Java RE which imposes it's own >>semantics for that command > 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' ? > Have a look at [1]. There you will find an example. > 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. > Any questions remaining? > > [1] http://www.opensc-project.org/opensc/ticket/252 -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On 15.01.2011 16:52, Andre Zepezauer wrote: > Hello Viktor, > > I know very well that my spelling isn't perfect but I have not expected > that the term "very special semantics" could be misunderstood. To get an > insight of the subject I was talking about please have a look at the > document attached to this mail: "Runtime Environment Specification". > > There you can find the semantics of the SELECT command defined for Java > Cards. Read section "3 Java Card Applet Lifetime" especially 3.2 and > 3.4. Hopefully the following becomes more clear. Is it so difficult to say a few words about the essential particularity? Thanks, I will look . 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. >> >> The whole process is nearly transparent. There are only two issues I >> encountered so far: >> * there is no MF per default, but it could be simulated by the applets >> * "SELECT BY NAME" is handled by the Java RE which imposes it's own >>semantics for that command > 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' ? > Have a look at [1]. There you will find an example. Thanks, I'll look. 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. > Any questions remaining? What about path to 'given application' for 'local' PINs ? > [1] http://www.opensc-project.org/opensc/ticket/252 -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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. M
Re: [opensc-devel] r5081
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. > >> > >> > >> Ple
Re: [opensc-devel] r5081
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
Re: [opensc-devel] r5081
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. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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
Re: [opensc-devel] r5081
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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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. The whole process is nearly transparent. There are only two issues I encountered so far: * there is no MF per default, but it could be simulated by the applets * "SELECT BY NAME" is handled by the Java RE which imposes it's own semantics for that command > Our card starts from EF.DIR. Everything that is above this file is out of > PKCS#15 context. > > > > > > Regards > > Andre > > Kind wishes, > Viktor. > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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. BTW care must be take with re-selecting an applet in Java Cards, because it may invalidate all previously verified PINs. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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 ? > Regards > Andre Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
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. >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. 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
Re: [opensc-devel] r5081
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. That's what sc_pkcs15_verify_pin() is actually doing. http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-pin.c#L246 > So, why trying to fix something that's not broken? No one said that something is broken. It's a kind reverence to some native PKCS#15 card structures that happens to not have 'path' in 'PinAttributes' for the local PINs. > BTW it segfaults. The 'valgrind' output or OpenSC debug logs would be greately appreciated . On of the possible reason is printing of not completely initialized 'sc_path' variables . 'AID' member was introduced into 'struct sc_path'. Actually in OpenSC source 'generally' this data type is initialized member by member, 'memset' is not always applied to the entire location . I was trying to track such a cases, but, probably, there are still some of them. Once more, your help would be appreciated a lot. > Regards > Andre Kind wishes, Viktor. > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] r5081
Hello Viktor, 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. So, why trying to fix something that's not broken? BTW it segfaults. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
