Re: [opensc-devel] Misleading information about capabilities of readers
Hello, > -Original Message- > > On 12.01.2011 18:41, Aventra wrote: > > My questions are: > > - have other OpenSC users tried cards that use T=1 protocol? > > - have somebody managed to use MyEID cards without adjusting the > > configuration? > > In OpenSC-trunk r5087 MyEID card is normally working (erase,init,import > PKCS#12) without changes in pcsc reader configuration section. > Maximal send/receive sizes 255/255. > The reader is OmniKey CardMan 3121. Thanks! This is good news, so perhaps it's only in a certain environment with specific Linux, pcsc-lite and ccid versions?? So this means we, for now, can keep the section on the MyEID wiki page, but change the phrase to something like "Some readers or environments...". > > -- > Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hi, Sorry, a typo when doing logging... Attached is a new log. Kind regards, Toni > -Original Message- > From: Ludovic Rousseau [mailto:ludovic.rouss...@gmail.com] > Sent: 12. tammikuuta 2011 19:29 > To: Aventra > Cc: opensc-devel > Subject: Re: [opensc-devel] Misleading information about capabilities of > readers > > 2011/1/12 Aventra : > > Hi, > > > > I have attached the requested logs. > > Try again with _exactly_ what is documented on the web page: > LIBCCID_ifdLogLevel=0x000F > export LIBCCID_ifdLogLevel > pcscd --foreground --debug --apdu > > Thanks > > -- > Dr. Ludovic Rousseau pcscd.log Description: Binary data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/13 Aventra : > Hi, > > Sorry, a typo when doing logging... > Attached is a new log. Found the bug (I think). The CCID driver calculate a timeout accordings to the card ATR. In your case the timeout is 1428 ms rounded to 2 seconds. Log says: 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds The same timeout is used by the reader and by the CCID driver. I think the CCID driver (libusb in fact) triggers its timeout just before the reader does. So the driver do not get the reader error message. Patch to try: in src/ifdhandler.c edit the function T1_card_timeout() (at the end of the file) and replace return timeout; by return timeout+1; Then regenerate a log again. Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 11:37 +0100, Ludovic Rousseau a écrit : > The CCID driver calculate a timeout accordings to the card ATR. In > your case the timeout is 1428 ms rounded to 2 seconds. Are all CCID readers impacted? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Jan 12, 2011, at 2:04 PM, Jean-Michel Pouré - GOOZE wrote: > Le mercredi 12 janvier 2011 à 13:26 +0200, Martin Paljak a écrit : >> >>> Per discussion, we have to pay to get the reader out of the >> unsupported >>> list, and this is quite a large sum of money. >> Pay whom? How much? Please be specific: who has to pay whom and how much? Name, sum in €, with any kind of extra fees (taxes, commissions, bribes) included. > I would say 'technical review', nothing special. Reviewing a smartcard > reader is a long job. This is probably the case. > > The libccid supported list is for companies which pay technical review. > When companies do not pay, readers are listed in "Should be supported". Are you talking about the open source CCID driver "unsupported" and "shouldwork" lists? I've been under the impression (based on the header in "shouldwork" list [1]) that it contains readers which work as expected and which Ludovic has. As is the case with OpenSC - we can only test what we have, and thus only support what we can test. So please fix my impression and help others who would want to know: how large is the sum of money one needs to pay? But keep in mind, that you as a company (or a manufacturer of hardware), who profit from people like Ludovic writing software that allows you to sell your products and make a profit, it is reasonable to expect that you either a) pay a premium and get some benefits b) not pay and be happy that your product works well with open source. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Dear all, > I've been under the impression (based on the header in "should work" > list [1]) that it contains readers which work as expected and which > Ludovic has. The names should be then: * Unsupported. * Supported (and not should work). * Supported and reviewed (and not Supported). > So please fix my impression and help others who would want to know: > how large is the sum of money one needs to pay? This information is none of my business. It cannot and shouldn't be posted in public. > But keep in mind, that you as a company (or a manufacturer of > hardware), who profit from people like Ludovic writing software that > allows you to sell your products and make a profit, it is reasonable > to expect that you either a) pay a premium and get some benefits b) > not pay and be happy that your product works well with open source. Sure, there is a difference between supported and reviewed. But the users should know the difference and not believe that the only "supported" devices are those from vendor which pay. Anyway, I am very grateful to Ludovic work. Are we really going to argue about that? IMHO, this is not interesting and I will not answer other emails. Sorry for that. Kind regards; -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Thu, 2011-01-13 at 11:37 +0100, Ludovic Rousseau wrote: > Found the bug (I think). > > The CCID driver calculate a timeout accordings to the card ATR. In > your case the timeout is 1428 ms rounded to 2 seconds. > Log says: > 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds > > The same timeout is used by the reader and by the CCID driver. I think > the CCID driver (libusb in fact) triggers its timeout just before the > reader does. So the driver do not get the reader error message. I don't think that libccid is the source of trouble. Check out this: grep -A 1 "3B\ F.\ 18\ ..\ ..\ 81\ 31\ FE\ 45" smartcard_list.txt Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Configure content of the log message
Hi,
what do you think about possibility to configure content of the log message.
I mean something like this in 'opensc.conf':
app default {
log_level = debug;
log debug {
debug = 8;
debug_file = /tmp/opensc-debug.log;
print_pid = false; #default true
print_timestamp = false; #default true
print_app_name = false; #default true
}
...
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] Creation of card pkcs#15 structure
Hi, >From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Viktor TARASOV > >Hello, > >On 11.01.2011 13:32, Aventra development wrote: >>What do you think about the possibility that when a card is initialized using pkcs15-init that it would create the whole structure that is defined in the profile used. >>Currently it only creates the necessary files during initialization, but not any private or public key DIR files etc, that are essential when actually using the card. > >It can be and, imho, has to be done. >There is no need of additional configuration option -- >condition to create xDF files during initialization is its 'CREATE' operation protected by SOPIN. > >In your profile, do you have different 'CREATE' ACLs for xDF and object data (for ex. certificates) files? No these are the same. It would be important if OpenSC would create the entire structure defined in the myeid.profile. How about other cards, is the entire structure created when initializing them? This issue does not affect OpenSC, because it can create the missing files, it is more about cross compatibility with other software that might know how to use the MyEID card (add certificate etc.) but will not create any PrKDF etc... >>After initialization the SO-PIN might not be given to the end user, since it might give them too much power over the card content and accidentally might mess it up. >> >>Kind regards, >>Toni > >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] Configure content of the log message
Hello,
OpenSC as a library doesn't need it's own logging system. Such things
are better placed at application level. If debugging is necessary, then
'export OPENSC_DEBUG=9' + pkcs11-spy works for me.
What would be the advantage of having logs of different instances of
OpenSC intermixed in a single file?
Regards
Andre
On Thu, 2011-01-13 at 16:14 +0100, Viktor TARASOV wrote:
> Hi,
>
> what do you think about possibility to configure content of the log message.
>
> I mean something like this in 'opensc.conf':
>
> app default {
> log_level = debug;
> log debug {
> debug = 8;
> debug_file = /tmp/opensc-debug.log;
>
> print_pid = false; #default true
> print_timestamp = false; #default true
> print_app_name = false; #default true
> }
> ...
>
>
> Kind wishes,
> Viktor.
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creation of card pkcs#15 structure
On 13.01.2011 16:43, Aventra wrote: > Hi, >> From: opensc-devel-boun...@lists.opensc-project.org >> [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Viktor >> TARASOV >> Hello, >> >> On 11.01.2011 13:32, Aventra development wrote: >>> What do you think about the possibility that when a card is initialized >>> using pkcs15-init that it would create the whole structure that is defined >>> in the profile used. >>> Currently it only creates the necessary files during initialization, but >>> not any private or public key DIR files etc, that are essential when >>> actually using the card. >>> >> It can be and, imho, has to be done. >> There is no need of additional configuration option -- condition to create >> xDF files during initialization is its 'CREATE' operation protected by >> SOPIN. >> In your profile, do you have different 'CREATE' ACLs for xDF and object data >> (for ex. certificates) files? > No these are the same. Do you use the myeid.profile that is actually in the trunk? Normally you don't need SoPIN if you use it. The essentials CREATE, UPDATE acls reference the User PIN. In my tests with opensc tools (import PKCS#12, key generation) SOPIN was not needed for MyEID card. Debug logs will be sufficiently eloquent. > It would be important if OpenSC would create the > entire structure defined in the myeid.profile. Agree in the case when 'CREATE' of the xDF files is protected by SOPIN. > How about other cards, is the entire structure created when initializing > them? Some of them use 'one-pin' profile, other do not protect with SOPIN the 'CREATE'/'UPDATE' operations of the 'essential' files. > This issue does not affect OpenSC, because it can create the missing files, > it is more about cross compatibility with other software that might know how > to use the MyEID card (add certificate etc.) but will not create any PrKDF > etc... > >>> After initialization the SO-PIN might not be given to the end user, since > it might give them too much power over the card content and accidentally > might mess it up. >>> >>> Kind regards, >>> Toni >> 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] Configure content of the log message
On 13.01.2011 17:07, Andre Zepezauer wrote:
> Hello,
>
> OpenSC as a library doesn't need it's own logging system. Such things
> are better placed at application level. If debugging is necessary, then
> 'export OPENSC_DEBUG=9' + pkcs11-spy works for me.
>
> What would be the advantage of having logs of different instances of
> OpenSC intermixed in a single file?
To have shorter line in logs,
"card.c:322:sc_unlock: called"
instead of
"0x2b20d02e53f0 17:50:57.667 [opensc-explorer] card.c:322:sc_unlock:
called"
Well, I do not see general enthusiasm, let's forget it.
> Regards
> Andre
Kind wishes,
Viktor.
> On Thu, 2011-01-13 at 16:14 +0100, Viktor TARASOV wrote:
>> Hi,
>>
>> what do you think about possibility to configure content of the log message.
>>
>> I mean something like this in 'opensc.conf':
>>
>> app default {
>> log_level = debug;
>> log debug {
>> debug = 8;
>> debug_file = /tmp/opensc-debug.log;
>>
>> print_pid = false; #default true
>> print_timestamp = false; #default true
>> print_app_name = false; #default true
>> }
>> ...
>>
>>
>> Kind wishes,
>> Viktor.
>>
>>
>> ___
>> opensc-devel mailing list
>> opensc-devel@lists.opensc-project.org
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
--
Viktor Tarasov
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Jean-Michel Pouré - GOOZE wrote: > > I've been under the impression (based on the header in "should work" > > list [1]) that it contains readers which work as expected and which > > Ludovic has. > > The names should be then: > * Unsupported. > * Supported (and not should work). > * Supported and reviewed (and not Supported). The good names depend on what "support" means in this context. I don't know that. Do you? Maybe Ludovic can help clarify? > > So please fix my impression and help others who would want to know: > > how large is the sum of money one needs to pay? > > This information is none of my business. > It cannot and shouldn't be posted in public. I disagree if I understand you correctly, but I am still not sure if I do.. :) libccid is an open source project, so can be assumed to have an open attitude. That said, things still cost money so if "supported" translates to some kind of commitment from anyone in the community for that project then of course there can be costs for listing a hardware as supported. And maybe those costs are negotiated on case by case basis, which is fine, but I see no reason to not make the process public. I'm less interested in the sums involved since I'm no reader vendor, but I am very curious to understand the process that you are describing, because it doesn't really fit my previous understanding - so maybe I overlooked something that you know more about, and I don't think it's a problem to share that knowledge? > Sure, there is a difference between supported and reviewed. "reviewed" is another term that I am now not at all sure if I understand correctly in this context. :) > But the users should know the difference and not believe that the > only "supported" devices are those from vendor which pay. I agree that it is important to have good definitions of terms. > Anyway, I am very grateful to Ludovic work. Me too! :) > Are we really going to argue about that? IMHO, this is not > interesting and I will not answer other emails. Sorry for that. I don't think we are arguing. It's good that you started this discussion, because it seems to me that there is a misunderstanding and I certainly want to have a clear understanding. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creation of card pkcs#15 structure
Hi, > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- > > On 13.01.2011 16:43, Aventra wrote: > >> From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- > boun...@lists.opensc-project.org] On Behalf Of Viktor TARASOV > >> > >> On 11.01.2011 13:32, Aventra development wrote: > >>> What do you think about the possibility that when a card is initialized > using pkcs15-init that it would create the whole structure that is defined in > the profile used. > >>> Currently it only creates the necessary files during initialization, but > not any private or public key DIR files etc, that are essential when actually > using the card. > >>> > >> It can be and, imho, has to be done. > >> There is no need of additional configuration option -- condition to create > xDF files during initialization is its 'CREATE' operation protected by SOPIN. > >> In your profile, do you have different 'CREATE' ACLs for xDF and object > data (for ex. certificates) files? > > No these are the same. > > Do you use the myeid.profile that is actually in the trunk? > Normally you don't need SoPIN if you use it. The essentials CREATE, UPDATE > acls reference the User PIN. > In my tests with opensc tools (import PKCS#12, key generation) SOPIN was not > needed for MyEID card. Yes I agree that normally the SO-PIN is not needed, but I think we are talking about different things now. Somebody might want to protect the card more than others. At least in Finland it is very common to have 3 PIN codes (basic, sign and so-pin), and the SO-PIN protects these xDF files from deletion (not update of course). > > Debug logs will be sufficiently eloquent. > > > > It would be important if OpenSC would create the > > entire structure defined in the myeid.profile. > Agree in the case when 'CREATE' of the xDF files is protected by SOPIN. I mean that I would like to have pkcs15-init create the entire pkcs#15 structure defined in the profile, no matter what the ACL:s are. Since other software doesn't know how to create these files if they don't exist. Now a card initialized with OpenSC can only be used with OpenSC until all necessary files have been created. No point in creating dummy keys only to get the file structure created... Kind regards, Toni > > > > How about other cards, is the entire structure created when initializing > > them? > Some of them use 'one-pin' profile, other do not protect with SOPIN the > 'CREATE'/'UPDATE' operations of the 'essential' files. > > > > This issue does not affect OpenSC, because it can create the missing files, > > it is more about cross compatibility with other software that might know how > > to use the MyEID card (add certificate etc.) but will not create any PrKDF > > etc... > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Jan 13, 2011, at 7:08 PM, Peter Stuge wrote: > Jean-Michel Pouré - GOOZE wrote: >>> I've been under the impression (based on the header in "should work" >>> list [1]) that it contains readers which work as expected and which >>> Ludovic has. >> >> The names should be then: >> * Unsupported. >> * Supported (and not should work). >> * Supported and reviewed (and not Supported). > > The good names depend on what "support" means in this context. I > don't know that. Do you? Maybe Ludovic can help clarify? > > >>> So please fix my impression and help others who would want to know: >>> how large is the sum of money one needs to pay? >> >> This information is none of my business. >> It cannot and shouldn't be posted in public. > > I disagree if I understand you correctly, but I am still not sure if > I do.. :) Private communication is supposed to be kept private, so no, I don't need the *exact* details either, the following text by Peter describes my questions as well. > libccid is an open source project, so can be assumed to have an open > attitude. > > That said, things still cost money so if "supported" translates to > some kind of commitment from anyone in the community for that project > then of course there can be costs for listing a hardware as > supported. And maybe those costs are negotiated on case by case > basis, which is fine, but I see no reason to not make the process > public. > > I'm less interested in the sums involved since I'm no reader vendor, > but I am very curious to understand the process that you are > describing, because it doesn't really fit my previous understanding - > so maybe I overlooked something that you know more about, and I don't > think it's a problem to share that knowledge? Same here. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Jan 13, 2011, at 7:08 PM, Peter Stuge wrote: > Jean-Michel Pouré - GOOZE wrote: >>> I've been under the impression (based on the header in "should work" >>> list [1]) that it contains readers which work as expected and which >>> Ludovic has. >> >> The names should be then: >> * Unsupported. >> * Supported (and not should work). >> * Supported and reviewed (and not Supported). > > The good names depend on what "support" means in this context. I > don't know that. Do you? Maybe Ludovic can help clarify? > > >>> So please fix my impression and help others who would want to know: >>> how large is the sum of money one needs to pay? >> >> This information is none of my business. >> It cannot and shouldn't be posted in public. > > I disagree if I understand you correctly, but I am still not sure if > I do.. :) > > libccid is an open source project, so can be assumed to have an open > attitude. > > That said, things still cost money so if "supported" translates to > some kind of commitment from anyone in the community for that project > then of course there can be costs for listing a hardware as > supported. And maybe those costs are negotiated on case by case > basis, which is fine, but I see no reason to not make the process > public. > > I'm less interested in the sums involved since I'm no reader vendor, > but I am very curious to understand the process that you are > describing, because it doesn't really fit my previous understanding - > so maybe I overlooked something that you know more about, and I don't > think it's a problem to share that knowledge? > > >> Sure, there is a difference between supported and reviewed. > > "reviewed" is another term that I am now not at all sure if I > understand correctly in this context. :) > > >> But the users should know the difference and not believe that the >> only "supported" devices are those from vendor which pay. > > I agree that it is important to have good definitions of terms. > > >> Anyway, I am very grateful to Ludovic work. > > Me too! :) > > >> Are we really going to argue about that? IMHO, this is not >> interesting and I will not answer other emails. Sorry for that. > > I don't think we are arguing. It's good that you started this > discussion, because it seems to me that there is a misunderstanding > and I certainly want to have a clear understanding. > > > //Peter > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 18:08 +0100, Peter Stuge a écrit : > > * Unsupported. > > * Supported (and not should work). > > * Supported and reviewed (and not Supported). > > The good names depend on what "support" means in this context. I > don't know that. Do you? Maybe Ludovic can help clarify? A word should always be used in the common sense. In free software, supported means that a hardware/software can run, until anyone can fill a bug report or indicate that it is not supported. And then people propose patches. This is the common sense of "supported". Take the example of smartcards in OpenSC. A lot of them are declared "supported", but presently only 3 or 4 work very well and are not end of life. Again: * Supported and reviewed by libccid author: Means that the hardware is supported and carefully reviewed. This is an indication of quality, but also that the vendor paid money. * Supported This is the usual meaning. Here is the R-301-v2. * Unsupported The reader did not fully pass the benchmark. There should be an indication of impact on OpenSC. If a reader is reported to work with OpenSC, users should know. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le 13 janvier 2011 18:39, Jean-Michel Pouré - GOOZE a écrit : > Le jeudi 13 janvier 2011 à 18:08 +0100, Peter Stuge a écrit : >> > * Unsupported. >> > * Supported (and not should work). >> > * Supported and reviewed (and not Supported). >> >> The good names depend on what "support" means in this context. I >> don't know that. Do you? Maybe Ludovic can help clarify? > > A word should always be used in the common sense. > > In free software, supported means that a hardware/software can run, > until anyone can fill a bug report or indicate that it is not supported. > And then people propose patches. This is the common sense of > "supported". Free free to support any reader you want to support. But I can't support a reader I do not have. So they are listed (by default) in the "Should work but untested by me" list. > Again: > * Supported and reviewed by libccid author: > Means that the hardware is supported and carefully reviewed. This is an > indication of quality, but also that the vendor paid money. > * Supported > This is the usual meaning. Here is the R-301-v2. > * Unsupported > The reader did not fully pass the benchmark. There should be an > indication of impact on OpenSC. If a reader is reported to work with > OpenSC, users should know. The readers listed on my 4 lists are not used only with OpenSC. So a reader may be listed in the "Unsupported or partly supported CCID readers" but work great with OpenSC. Also note that readers listed in "Supported CCID readers/ICCD tokens", "Should work but untested by me" and "Unsupported or partly supported CCID readers" are all usable with my CCID driver. Only readers in the "Disabled CCID readers" are not working at all and are not recognized by my CCID driver. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Thu, 2011-01-13 at 18:39 +0100, Jean-Michel Pouré - GOOZE wrote: > Le jeudi 13 janvier 2011 à 18:08 +0100, Peter Stuge a écrit : > > > * Unsupported. > > > * Supported (and not should work). > > > * Supported and reviewed (and not Supported). > > > > The good names depend on what "support" means in this context. I > > don't know that. Do you? Maybe Ludovic can help clarify? > > A word should always be used in the common sense. > > In free software, supported means that a hardware/software can run, > until anyone can fill a bug report or indicate that it is not supported. > And then people propose patches. This is the common sense of > "supported". > > Take the example of smartcards in OpenSC. A lot of them are declared > "supported", but presently only 3 or 4 work very well and are not end of > life. > > Again: > * Supported and reviewed by libccid author: > Means that the hardware is supported and carefully reviewed. This is an > indication of quality, but also that the vendor paid money. It would be easier to call it 'certified'. And of cause, certification may be a service that is not for free. > * Supported > This is the usual meaning. Here is the R-301-v2. > * Unsupported > The reader did not fully pass the benchmark. There should be an > indication of impact on OpenSC. If a reader is reported to work with > OpenSC, users should know. > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 18:47 +0100, Ludovic Rousseau a écrit : > But I can't support a reader I do not have. So they are listed (by > default) in the "Should work but untested by me" list. You have the R-301 v2. I shipped it to you and I have an email telling us that you received it. It is listed as Feitian Technologies FT SCR310. So why is it in "Should work but untested by me". -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creation of card pkcs#15 structure
On 13.01.2011 18:23, Aventra wrote: > Hi, > >> From: opensc-devel-boun...@lists.opensc-project.org >> [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Viktor >> TARASOV >> Do you use the myeid.profile that is actually in the trunk? >> Normally you don't need SoPIN if you use it. The essentials CREATE, UPDATE >> acls reference the User PIN. >> In my tests with opensc tools (import PKCS#12, key generation) SOPIN was not >> needed for MyEID card. > Yes I agree that normally the SO-PIN is not needed, but I think we are > talking about different things now. > Somebody might want to protect the card more than others. At least in > Finland it is very common to have 3 PIN codes (basic, sign and so-pin), > and the SO-PIN protects these xDF files from deletion (not update of > course). So, you are talking about profile that is more protected then the one that is actually in trunk. What do you think, will it be sufficient, during the card initialization, to create all xDF files that have 'CREATE' protected by SOPIN ? If yes, we don't need additional profile configuration option. If not, probably, we have to introduce some new profile configuration option like 'create-all-xdfs', or 'create-at-initialisation' option for every xDF file in profile, etc ... >>> It would be important if OpenSC would create the >>> entire structure defined in the myeid.profile. >> Agree in the case when 'CREATE' of the xDF files is protected by SOPIN. > I mean that I would like to have pkcs15-init create the entire pkcs#15 > structure defined in the profile, no matter what the ACL:s are. > Since other software doesn't know how to create these files if they don't > exist. You still need to create certificate files, data files, probably more ... They cannot have the same 'protected' ACLs as the xDFs. On 13.01.2011 16:43, Aventra wrote: >> >> From:opensc-devel-boun...@lists.opensc-project.org >> >> [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of >> >> Viktor TARASOV >> >> In your profile, do you have different 'CREATE' ACLs for xDF and object >> >> data (for ex. certificates) files? > > No these are the same. They cannot have the same 'protected' ACLs as the xDFs. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 18:52 +0100, Andre Zepezauer a écrit : > It would be easier to call it 'certified'. And of cause, certification > may be a service that is not for free. I second that. Certification is loud and clear. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Configure content of the log message
On Thu, 2011-01-13 at 17:58 +0100, Viktor TARASOV wrote:
> On 13.01.2011 17:07, Andre Zepezauer wrote:
> > Hello,
> >
> > OpenSC as a library doesn't need it's own logging system. Such things
> > are better placed at application level. If debugging is necessary, then
> > 'export OPENSC_DEBUG=9' + pkcs11-spy works for me.
> >
> > What would be the advantage of having logs of different instances of
> > OpenSC intermixed in a single file?
>
> To have shorter line in logs,
> "card.c:322:sc_unlock: called"
> instead of
> "0x2b20d02e53f0 17:50:57.667 [opensc-explorer] card.c:322:sc_unlock:
> called"
Making the lines shorter isn't that bad. But making it configurable is a
lot of overhead. Personally I wouldn't miss anything if a line would
look like this: "card.c:322:sc_unlock: called"
> Well, I do not see general enthusiasm, let's forget it.
>
> > Regards
> > Andre
> Kind wishes,
> Viktor.
>
>
> > On Thu, 2011-01-13 at 16:14 +0100, Viktor TARASOV wrote:
> >> Hi,
> >>
> >> what do you think about possibility to configure content of the log
> >> message.
> >>
> >> I mean something like this in 'opensc.conf':
> >>
> >> app default {
> >> log_level = debug;
> >> log debug {
> >> debug = 8;
> >> debug_file = /tmp/opensc-debug.log;
> >>
> >> print_pid = false; #default true
> >> print_timestamp = false; #default true
> >> print_app_name = false; #default true
> >> }
> >> ...
> >>
> >>
> >> Kind wishes,
> >> Viktor.
> >>
> >>
> >> ___
> >> opensc-devel mailing list
> >> opensc-devel@lists.opensc-project.org
> >> http://www.opensc-project.org/mailman/listinfo/opensc-devel
> >
>
>
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] libccid device list
Dear members, I have been reviewing libccid pages. Here are copies to keep a trace: <-- Begin of copy * http://pcsclite.alioth.debian.org/ccid/supported.html If you are a reader manufacturer and your reader is not listed here then contact me at ... * http://pcsclite.alioth.debian.org/ccid/shouldwork.html Should work but untested by me The CCID readers and ICCD tokens listed bellow should work with the driver but have not be validated by me. I would like to get these readers to perform test and validation and move them in the supported list above. If you are one of the manufacturers, please, contact me at ... --> End of copy A normal user would believe that the author is just asking for a free reader from the manufacturer. I gave the ePass PKI token and shipped the R-301-v2 to the author, and never got in the supported list. In reply, the author asked for a sum of money for technical review. IMHO, it is clear that the support page is an commercial offer of a certification service. To me, this creates several problems: * Libccid is a work from several authors and they have a right to say which readers are supported or not. At least to decide which words are used. * From a moral point of view, free software is always clear what is free and what has to be paid, including hardware or software compliance list. Here, this is not very clear, for vendors and end-users. Some vendors may not understand the nature of the list. Some users may really believe that ONLY the readers from the supported list are really supported. * The testing software may have small bugs, here and there. For example, what is the impact of the libusb timeout issue. But this could be anything. Per discussion on the mailing list, my proposed sections would be : * Supported and certified by the author (commercial service, to become certified, please send an email to learn about the price and procedure). * Supported and untested by the author. * Partial support (may work, some errors reported during test). * Incompatible (should never be used, removed from ccid list). Most software editors offer certification services. So why not libccid. There could be a libccid supported logo. From a commercial point of view, this may be a superior approach for the author. Everyone will gain from that, IMHO. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ 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
Re: [opensc-devel] libccid device list
Le 13 janvier 2011 23:35, Jean-Michel Pouré - GOOZE a écrit : > Per discussion on the mailing list, my proposed sections would be : > > * Supported and certified by the author (commercial service, to become > certified, please send an email to learn about the price and procedure). > * Supported and untested by the author. > * Partial support (may work, some errors reported during test). > * Incompatible (should never be used, removed from ccid list). Feel free to fork the libccid project and manage the lists of readers as you want on your own web site. It is free software. But please don't tell me what I have to do. Stop Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
