Re: [opensc-devel] Consistence between the OpenSC and proprietary drivers

[Weitao Sun]

On 1/11/2011 10:50 PM, Jan Just Keijser wrote:
> Hi all,
>
> Viktor TARASOV wrote:
>> On 11.01.2011 09:23, Xiaoshuo Wu wrote:
>>   
>>> On Mon, 10 Jan 2011 16:50:37 +0800, Viktor TARASOV 
>>>  wrote:
>>>
>>> 
 Do we have any chance to influence the card producer and to change 
 behavior of their middlewares ?
 If so, then it make a sense to wait.
   
>>> OpenSC compatibility is an important feature in Feitian's current 
>>> middleware.
>>> New model will also be OpenSC compatible.
>>>
>>> 
>> Sun is really raising in the East.
>>
>>   
> I've been reading this discussion and a question comes to mind.
>
> The Feitian cards work with the OpenSC driver
> The Feitian cards also work with the proprietary driver from Feitian 
> itself, in a way that is almost 100% compatible with OpenSC.

It's PKCS#15 format for interoperability, and the compatibility with
OpenSC is among the most important test cases. Moreover, Feitian's token
support secret key objects stored in PKCS#15 format, which haven't been
supported by OpenSC by now.

Even with these efforts, it's not 100% compatible with OpenSC. Sorry, we
tried to, but failed. We could have managed to achieve this if we get
rid of one of the key features in proprietary driver. As a result,
Feitian's software refuse to write(not read) smart cards formatted by
OpenSC, and vice versa.





___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] ruToken question

[Viktor TARASOV]

On 11.01.2011 09:03, Aktiv Co. Kirill Mescheryakov wrote:


Rutoken device with with vid=0x0a89 and pid=0x0004 is earlier version of Aktiv 
Rutoken S  Device.

It contains several errors in PCSC layer and supported only by Aktiv Co. 
proprietary windows drivers and libs.

These devices are not supported by OpenSC. These are not CCID too.

>> On Windows also I do not succeeded to access this token .
>> (I was trying to uses drivers from 
http://www.rutoken.ru/hotline/download/drivers/)

This should work.

What is the problem you encountered?



I try to use it in Windows XP running in VMware.
The driver package has installed three 'Activ. Co Ifd' handlers, that seems 
working properly, but token is not detected by 'rtAdmin' or similar tools.



Best regards, Cyril.



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] Misleading information about capabilities of readers

[Ludovic Rousseau]

2011/1/11 Andre Zepezauer :
> Hello,
>
> the wiki page of MyEID [1] contains the following paragraph:
>
> "Many readers don't support receiving the default amount of data (254).
> Problems will only appear when reading larger files from the card (e.g.
> certificates). So if you have problems with reading the card with no
> apparent reason, try to set this to e.g. 192, to be on the safe side.
> You can then try to iterate to find the maximum for your card reader."
>
> That statement is simply wrong, because every USB reader can handle
> Short-APDUs of every size. For that reason no other card has similar
> problems.

Every _non-bogus_ reader.
For example the Feitian SCR301 [2] is bogus and can't support CASE 2
APDU with Le=0 (256 bytes). That is why this reader is listed in the
"unsupported" list of my CCID driver.

> If there are readers that don't work properly with MyEID, then list them
> explicitly by name. That would definitely of more help to users then
> such a vague statement like "Many readers don't support [...]".

The reader above has a problem with Le=256. Le=254 should work and the
reader should not have a problem with MyEID.

I don't know which readers have problem with MyEID. An explicit list
of bogus readers would be great so that users can avoid buying such
readers.

Bye

> [1] http://www.opensc-project.org/opensc/wiki/MyEID
[2] http://pcsclite.alioth.debian.org/ccid/unsupported.html#0x096E0x0503

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

[Aventra development]

Hi,

Well this is just something we (and our customers) have encountered with the
readers that we have tested.
I don't know what causes the limitation (probably not the reader itself,
because they work in windows just fine). 
So it might be in pcsc-lite, the ccid driver or something to do with usb in
linux??

Readers we have tested are:
- ACS ACR38 CCID
- Gemalto Twin Reader
- and some OmniKey reader (maybe 3121 if remember correctly)

All of these have the same issue, so I suspect that they are not the cause
of the problem. 
Many of our customers have had the same problem and setting this value has
helped also them, so it is not only in our environment.

We have not investigated this further, because this setting solves the
problem, and does not affect performance that much that it would matter.

Kind regards,
Toni

> -Original Message-
> From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
> Sent: 12. tammikuuta 2011 0:21
> To: Aventra development
> Cc: opensc-devel
> Subject: Misleading information about capabilities of readers
> 
> Hello,
> 
> the wiki page of MyEID [1] contains the following paragraph:
> 
> "Many readers don't support receiving the default amount of data (254).
> Problems will only appear when reading larger files from the card (e.g.
> certificates). So if you have problems with reading the card with no
> apparent reason, try to set this to e.g. 192, to be on the safe side.
> You can then try to iterate to find the maximum for your card reader."
> 
> That statement is simply wrong, because every USB reader can handle
> Short-APDUs of every size. For that reason no other card has similar
> problems.
> 
> If there are readers that don't work properly with MyEID, then list them
> explicitly by name. That would definitely of more help to users then
> such a vague statement like "Many readers don't support [...]".
> 
> Regards
> Andre
> 
> [1] http://www.opensc-project.org/opensc/wiki/MyEID
> 
> 


___
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

[Martin Paljak]

Hello,
On Jan 12, 2011, at 11:34 AM, Aventra development wrote:
> Readers we have tested are:
> - ACS ACR38 CCID
This is a very broad range, ACS re-uses the chip in different incarnations in 
several products that are marketed under different names and I would not bet on 
it being 100% the same chip (firmware) all the time.

> - Gemalto Twin Reader
> - and some OmniKey reader (maybe 3121 if remember correctly)
> 
> All of these have the same issue, so I suspect that they are not the cause
> of the problem. 
> Many of our customers have had the same problem and setting this value has
> helped also them, so it is not only in our environment.
> 
> We have not investigated this further, because this setting solves the
> problem, and does not affect performance that much that it would matter.
Please provide a failing OpenSC debug log.


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

[Martin Paljak]

Hello,

On Jan 12, 2011, at 11:22 AM, Ludovic Rousseau wrote:
> Every _non-bogus_ reader.
> For example the Feitian SCR301 [2] is bogus and can't support CASE 2
> APDU with Le=0 (256 bytes). That is why this reader is listed in the
> "unsupported" list of my CCID driver.

Interesting. Too bad the original problem description [1] from the commit 
message is not available any more.
Jean-Michel, what were the symptoms of the bug?

[1] 
http://www.gooze.eu/forums/support/gnu-linux/can-t-get-feitian-r-301-reader-to-work-with-feitian-pki-card

-- 
@MartinPaljak.net
+3725156495

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Cryptoflex unsupprted?

[François Schauber]

Hi,

I just discovered OpenSC. I try to read my card, a Cryptoflex, but it seems
unsupported.

D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0 -a
3b:95:18:40:14:64:02:01:01:02

D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0 --name
Unsupported card

Are all the card drivers included in OpenSC or we can download it somewhere?

Thx,
François
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Cryptoflex unsupprted?

[Martin Paljak]

Hello,

On Jan 12, 2011, at 11:53 AM, François Schauber wrote:

> Hi,
> 
> I just discovered OpenSC. I try to read my card, a Cryptoflex, but it seems 
> unsupported.
> 
> D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0 -a
> 3b:95:18:40:14:64:02:01:01:02
This seems like an unknown card [1]



> 
> D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0 --name
> Unsupported card
> 
> Are all the card drivers included in OpenSC or we can download it somewhere?
All are included by default.

Try forcing the driver as instructed in opensc.conf or add the ATR to the 
src/libopensc/card-flex.c file yourself.


[1] http://smartcard-atr.appspot.com/parse?ATR=3B951840146402010102

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

[Aventra development]

Hi,

> -Original Message-
> From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-
> boun...@lists.opensc-project.org] On Behalf Of Ludovic Rousseau
> Sent: 12. tammikuuta 2011 11:22
> To: opensc-devel
> Subject: Re: [opensc-devel] Misleading information about capabilities of
> readers
> 
> 2011/1/11 Andre Zepezauer :
> > Hello,
> >
> > the wiki page of MyEID [1] contains the following paragraph:
> >
> > "Many readers don't support receiving the default amount of data (254).
> > Problems will only appear when reading larger files from the card (e.g.
> > certificates). So if you have problems with reading the card with no
> > apparent reason, try to set this to e.g. 192, to be on the safe side.
> > You can then try to iterate to find the maximum for your card reader."
> >
> > That statement is simply wrong, because every USB reader can handle
> > Short-APDUs of every size. For that reason no other card has similar
> > problems.
> 
> Every _non-bogus_ reader.
> For example the Feitian SCR301 [2] is bogus and can't support CASE 2
> APDU with Le=0 (256 bytes). That is why this reader is listed in the
> "unsupported" list of my CCID driver.
> 
> > If there are readers that don't work properly with MyEID, then list them
> > explicitly by name. That would definitely of more help to users then
> > such a vague statement like "Many readers don't support [...]".
> 
> The reader above has a problem with Le=256. Le=254 should work and the
> reader should not have a problem with MyEID.
> 
> I don't know which readers have problem with MyEID. An explicit list
> of bogus readers would be great so that users can avoid buying such
> readers.


There is nothing special about MyEID that would cause the issue. In windows
everything works just fine if we follow the readers maxIFSD value.
One difference with many other cards supported by OpenSC that they use T=0
protocol (MyEID use T=1).
We have not investigated this further, because the setting solves the
problem.

Kind regards,
Toni

> 
> Bye
> 
> > [1] http://www.opensc-project.org/opensc/wiki/MyEID
> [2] http://pcsclite.alioth.debian.org/ccid/unsupported.html#0x096E0x0503
> 
> --
>  Dr. Ludovic Rousseau
> ___
> 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] Cryptoflex unsupprted?

[Andre Zepezauer]

Hello,

On Wed, 2011-01-12 at 10:53 +0100, François Schauber wrote:
> Hi,
> 
> I just discovered OpenSC. I try to read my card, a Cryptoflex, but it
> seems unsupported.
> 
> D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0 -a
> 3b:95:18:40:14:64:02:01:01:02
> 
> D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0
> --name
> Unsupported card
> 
> Are all the card drivers included in OpenSC or we can download it
> somewhere?

All drivers are included. But it's possible to re-configure a specific
driver to serve your card too. In your case, you have to add the
following lines to /etc/opensc.conf:

card_atr 3b:95:18:40:14:64:02:01:01:02 {
name = "Unknown-Cryptoflex";
driver = "flex";
}

Which version are you running? 'opensc-tool -i'

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] small change in build script to build with cardmod.

[francois . leblanc]

Hello Alon,

I've noticed that you remove --enable-cardmod on build scripts

due to licence issue, it's ok for me but to permit building cardmod

simply I wish add the possiblity to set extra_opensc=--enable-cardmod 

in command line so :

to enable cardmod:

CHOST=i586-pc-mingw32 CBUILD=i686-pc-linux extra_opensc=--enable-cardmod 
build

without cardmod:

CHOST=i586-pc-mingw32 CBUILD=i686-pc-linux build

This need to remove/comment line:

local extra_opensc

in build script,

do you mind if I comment this line?


Regards
François.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Cryptoflex unsupprted?

[François Schauber]

D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe -i
opensc 0.12.0 [gcc  4.4.4]
Enabled features: zlib openssl pcsc(winscard.dll)

I added the lines in the opensc.conf but it's not enough, i assume it's
necessary to add the lines to treat the APDU treatment specific to this
Cryptoflex card.

2011/1/12 Andre Zepezauer 

> Hello,
>
> On Wed, 2011-01-12 at 10:53 +0100, François Schauber wrote:
> > Hi,
> >
> > I just discovered OpenSC. I try to read my card, a Cryptoflex, but it
> > seems unsupported.
> >
> > D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0 -a
> > 3b:95:18:40:14:64:02:01:01:02
> >
> > D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe --reader 0
> > --name
> > Unsupported card
> >
> > Are all the card drivers included in OpenSC or we can download it
> > somewhere?
>
> All drivers are included. But it's possible to re-configure a specific
> driver to serve your card too. In your case, you have to add the
> following lines to /etc/opensc.conf:
>
> card_atr 3b:95:18:40:14:64:02:01:01:02 {
>name = "Unknown-Cryptoflex";
>driver = "flex";
> }
>
> Which version are you running? 'opensc-tool -i'
>
> Regards
> Andre
>
>
___
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

[Andre Zepezauer]

On Wed, 2011-01-12 at 12:26 +0200, Aventra development wrote:
> Hi,
> 
> > -Original Message-
> > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-
> > boun...@lists.opensc-project.org] On Behalf Of Ludovic Rousseau
> > Sent: 12. tammikuuta 2011 11:22
> > To: opensc-devel
> > Subject: Re: [opensc-devel] Misleading information about capabilities of
> > readers
> > 
> > 2011/1/11 Andre Zepezauer :
> > > Hello,
> > >
> > > the wiki page of MyEID [1] contains the following paragraph:
> > >
> > > "Many readers don't support receiving the default amount of data (254).
> > > Problems will only appear when reading larger files from the card (e.g.
> > > certificates). So if you have problems with reading the card with no
> > > apparent reason, try to set this to e.g. 192, to be on the safe side.
> > > You can then try to iterate to find the maximum for your card reader."
> > >
> > > That statement is simply wrong, because every USB reader can handle
> > > Short-APDUs of every size. For that reason no other card has similar
> > > problems.
> > 
> > Every _non-bogus_ reader.
> > For example the Feitian SCR301 [2] is bogus and can't support CASE 2
> > APDU with Le=0 (256 bytes). That is why this reader is listed in the
> > "unsupported" list of my CCID driver.
> > 
> > > If there are readers that don't work properly with MyEID, then list them
> > > explicitly by name. That would definitely of more help to users then
> > > such a vague statement like "Many readers don't support [...]".
> > 
> > The reader above has a problem with Le=256. Le=254 should work and the
> > reader should not have a problem with MyEID.
> > 
> > I don't know which readers have problem with MyEID. An explicit list
> > of bogus readers would be great so that users can avoid buying such
> > readers.
> 
> 
> There is nothing special about MyEID that would cause the issue. In windows
> everything works just fine if we follow the readers maxIFSD value.
> One difference with many other cards supported by OpenSC that they use T=0
> protocol (MyEID use T=1).

I have a guess about the source of trouble: MyEID cards do not support
T1-Block-Chaining.

@Ludovic: What's your opinion?

___
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

[Ludovic Rousseau]

2011/1/12 Andre Zepezauer :
> On Wed, 2011-01-12 at 12:26 +0200, Aventra development wrote:
>> There is nothing special about MyEID that would cause the issue. In windows
>> everything works just fine if we follow the readers maxIFSD value.
>> One difference with many other cards supported by OpenSC that they use T=0
>> protocol (MyEID use T=1).
>
> I have a guess about the source of trouble: MyEID cards do not support
> T1-Block-Chaining.
>
> @Ludovic: What's your opinion?

I need a pcscd trace to know.
Use the Gemalto Twin reader to generate the trace and follow [1].

You can also join the associated opensc debug trace.

Thanks

[1] http://pcsclite.alioth.debian.org/ccid.html#support

-- 
 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] Braking change in OpenSC 0.12.0 tokenInfo

[Kalev Lember]

On 01/11/2011 06:21 PM, Mr Dash Four wrote:
>
>>> Something like that might actually warrant a new point release of
>>> opensc to make sure Linux distros pick up the fix.
>>
>> Having a point release for every single bug fix would be overkill. So
>> the question is, what's the best approach to quickly distribute
>> important fixes? What would fit the workflow of the package maintainers?
>> Any suggestions?
> May be distribute a patch with the fix directly with the various
> distributors and make a 'dash' release (i.e. 12.0-2) - at least that is
> how it works, I think, with FC.

Putting my Fedora packager hat on, please release new tarballs if you
have important bugfixes to distribute. This ensures everybody is using
the same code and makes problems much easier to debug.

-- 
Kalev
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Cryptoflex unsupprted?

[Andre Zepezauer]

On Wed, 2011-01-12 at 11:44 +0100, François Schauber wrote:
> D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe -i
> opensc 0.12.0 [gcc  4.4.4]
> Enabled features: zlib openssl pcsc(winscard.dll)
> 
> I added the lines in the opensc.conf but it's not enough, i assume
> it's necessary to add the lines to treat the APDU treatment specific
> to this Cryptoflex card.

The given configuration should be sufficient to attach the Cryptoflex
driver to your card. I have tested it locally and had successfully
attached Cryptoflex driver to OpenPGP card:

card_atr 3B:FA:13:00:FF:81:31:80:45:00:31:C1:73:C0:01:00:00:90:00:B1 {
name = "Unknown Cyberflex";
driver = "flex";
}

Please provide debug logs. 'export OPENSC_DEBUG=9'


> 2011/1/12 Andre Zepezauer 
> Hello,
> 
> 
> On Wed, 2011-01-12 at 10:53 +0100, François Schauber wrote:
> > Hi,
> >
> > I just discovered OpenSC. I try to read my card, a
> Cryptoflex, but it
> > seems unsupported.
> >
> > D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe
> --reader 0 -a
> > 3b:95:18:40:14:64:02:01:01:02
> >
> > D:\Program Files\OpenSC Project\OpenSC>opensc-tool.exe
> --reader 0
> > --name
> > Unsupported card
> >
> > Are all the card drivers included in OpenSC or we can
> download it
> > somewhere?
> 
> 
> All drivers are included. But it's possible to re-configure a
> specific
> driver to serve your card too. In your case, you have to add
> the
> following lines to /etc/opensc.conf:
> 
> card_atr 3b:95:18:40:14:64:02:01:01:02 {
>name = "Unknown-Cryptoflex";
>driver = "flex";
> }
> 
> Which version are you running? 'opensc-tool -i'
> 
> Regards
> Andre
> 
> 

___
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]

Le mercredi 12 janvier 2011 à 12:07 +0200, Martin Paljak a écrit :
> Jean-Michel, what were the symptoms of the bug?

Feitian R-301 was updated recently with a new CCID firmware, 
which works fine:
http://www.gooze.eu/feitian-r-301-v2

In the CCID database, it is listed as the Feitian SCR310:
http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x096E0x0505

But we call the reader the Feitian R-301 v2.

As for R-301-v1, it used to have an unsupported message, but it proved
to be an OpenCT incompatibility. So everything was fine. 

We never had any problem with the R-301 v1.
We never had a single return of the R-301 v1. 

This is good to do libCCID automatic testing, but when an error has no
impact of OpenSC, it is unfair to keep listing a reader in the
unsupported list. 

Per discussion, we have to pay to get the reader out of the unsupported
list, and this is quite a large sum of money. 

So our official position is:
* If you own an R-301v1 reader and you have incompatibility problems,
then ship it back to us so that we can reproduce the problem. We will
replace it with an R-301 v2 at no cost. We are really interested, as it
never arrived before.
* The R-301 v2 works perfectly.

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] Braking change in OpenSC 0.12.0 tokenInfo

[Jean-Michel Pouré - GOOZE]

Le mercredi 12 janvier 2011 à 13:07 +0200, Kalev Lember a écrit :
> 
> Putting my Fedora packager hat on, please release new tarballs if you
> have important bugfixes to distribute. This ensures everybody is using
> the same code and makes problems much easier to debug. 

I also second this approach:
* Debugging OpenSC svn during 1 year = 50 testers.
* Releasing OpenSC every one month = 50.000 testers.

So the choice is clear to me.
Time-based releases + frequent releases is superior.

User like it and does not give packagers too much overhead.
On the converse, packages have to manage less bugs.
-- 
  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

[Martin Paljak]

On Jan 12, 2011, at 1:22 PM, Jean-Michel Pouré - GOOZE wrote:

> Le mercredi 12 janvier 2011 à 12:07 +0200, Martin Paljak a écrit :
>> Jean-Michel, what were the symptoms of the bug?
> 
> As for R-301-v1, it used to have an unsupported message, but it proved
> to be an OpenCT incompatibility. So everything was fine. 
Is the original description available?

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


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

[Jean-Michel Pouré - GOOZE]

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? 

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

Therefore, some companies, are more visible on Internet.

In our case, about the R-301-v1, from I remember, the error was just a
timeout. It had no impact on OpenSC and to speak frankly, I doubt this
was a problem as we never had ONE product return.

Also, I don't want to go further into discussions about theses issues.
Members of the mailing list, especially those using the R-301-v1 can
have their own mind. Again, if you have a problem with the R-301-v1,
drop me an email on GOOZE and I will replace your reader. But I doubt
this will happen.
-- 
  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

[Aventra development]

Hi,

> -Original Message-
> From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
> Sent: 12. tammikuuta 2011 12:46
> >
> > There is nothing special about MyEID that would cause the issue. In
windows
> > everything works just fine if we follow the readers maxIFSD value.
> > One difference with many other cards supported by OpenSC that they use
T=0
> > protocol (MyEID use T=1).
> 
> I have a guess about the source of trouble: MyEID cards do not support
> T1-Block-Chaining.

MyEID supports this block chaining because it is based on standard NXP JCOP
smartcard chips. 
However, block chaining is used only after the maximum packet size is
reached, i.e. above 256 bytes, 
so it would not be used here anyway.

>From our point of view, this is handled totally transparently by the reader
and the smartcard chip.
 
Kind regards,
Toni

___
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

[Andre Zepezauer]

On Wed, 2011-01-12 at 17:22 +0200, Aventra development wrote:
> Hi,
> 
> > -Original Message-
> > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
> > Sent: 12. tammikuuta 2011 12:46
> > >
> > > There is nothing special about MyEID that would cause the issue. In
> windows
> > > everything works just fine if we follow the readers maxIFSD value.
> > > One difference with many other cards supported by OpenSC that they use
> T=0
> > > protocol (MyEID use T=1).
> > 
> > I have a guess about the source of trouble: MyEID cards do not support
> > T1-Block-Chaining.
> 
> MyEID supports this block chaining because it is based on standard NXP JCOP
> smartcard chips. 
> However, block chaining is used only after the maximum packet size is
> reached, i.e. above 256 bytes, 
> so it would not be used here anyway.
> 
> From our point of view, this is handled totally transparently by the reader
> and the smartcard chip.

Manually adjusting max_*_size to some magic value isn't transparent at
all. So the question is, why MyEID needs such adjustment whereas other
cards don't. You should definitely start investigating that issue.

As a short term solution you could provide a list of readers known to
work. That would be most valuable for your customers.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Consistence between the OpenSC and proprietary drivers

[Douglas E. Engert]

On 1/12/2011 1:54 AM, francois.lebl...@cev-sa.com wrote:

>
> I don't try this, but trainee that make some tests and manage to start
> login,
>
> but server refuse the certificat (don't have exactly the cause).
>
> So I guess that opensc successfully start...
>
>
> The best way is to have a one build dll carmod.dll without need of
> external dll
>
> (libtool, etc...) and put it in system32.
>
>

You say the server refuses the certificate. The Windows login would
be to Active Directory using the Kerberos PKINIT protocols.

Have you setup AD to trust the CA that signed the certificate?

http://support.microsoft.com/kb/281245

See "Request a smart card certificate from the third-party CA."
that covers what must be in the certificate for it to work with login
and what changes are needed in the domain controller to accept
PKINIT.

To make testing easier, rather then login, you can also try:

  runas /smartcard /user u...@doamin /netonly cmd.exe

This will test the smartcard and the PKINIT, and is a lot easier then
trying login, and easier to run a wireshark trace to see what is going
over the network.

-- 

  Douglas E. Engert  
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Supported algo references in 'sc_pkcs15_prkey_info'

[Viktor TARASOV]

Hello,

I would like to introduce the array of algorithm references supported by key
into the 'pkcs15 private/public key info' data.

This issue was discussed in
http://www.opensc-project.org/pipermail/opensc-devel/2010-September/014921.html
and it seems that community was not hostile to this demand.

If no objections, I will proceed.

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] Misleading information about capabilities of readers

[Ludovic Rousseau]

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

[Aventra]

Hi,

> -Original Message-
> > > -Original Message-
> > > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
> > > Sent: 12. tammikuuta 2011 12:46
> > > >
> > > > There is nothing special about MyEID that would cause the issue. In
> > windows
> > > > everything works just fine if we follow the readers maxIFSD value.
> > > > One difference with many other cards supported by OpenSC that they
use
> > T=0
> > > > protocol (MyEID use T=1).
> > >
> > > I have a guess about the source of trouble: MyEID cards do not support
> > > T1-Block-Chaining.
> >
> > MyEID supports this block chaining because it is based on standard NXP
JCOP
> > smartcard chips.
> > However, block chaining is used only after the maximum packet size is
> > reached, i.e. above 256 bytes,
> > so it would not be used here anyway.
> >
> > From our point of view, this is handled totally transparently by the
reader
> > and the smartcard chip.
> 
> Manually adjusting max_*_size to some magic value isn't transparent at
> all. So the question is, why MyEID needs such adjustment whereas other
> cards don't. You should definitely start investigating that issue.

Yes, I agree that this is something that we would not want to do, but we are
stuck with it for the moment.

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?

> As a short term solution you could provide a list of readers known to
> work. That would be most valuable for your customers.

Since we have only encountered readers that require the configuration tweak,
we have decided to add the information on how to change the configuration to
the wiki page.
Hope this can be solved somehow in the future.

Kind regards,
Toni 

> Regards
> Andre

___
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

[Andre Zepezauer]

On Wed, 2011-01-12 at 19:41 +0200, Aventra wrote:
> Hi,
> 
> > -Original Message-
> > > > -Original Message-
> > > > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
> > > > Sent: 12. tammikuuta 2011 12:46
> > > > >
> > > > > There is nothing special about MyEID that would cause the issue. In
> > > windows
> > > > > everything works just fine if we follow the readers maxIFSD value.
> > > > > One difference with many other cards supported by OpenSC that they
> use
> > > T=0
> > > > > protocol (MyEID use T=1).
> > > >
> > > > I have a guess about the source of trouble: MyEID cards do not support
> > > > T1-Block-Chaining.
> > >
> > > MyEID supports this block chaining because it is based on standard NXP
> JCOP
> > > smartcard chips.
> > > However, block chaining is used only after the maximum packet size is
> > > reached, i.e. above 256 bytes,
> > > so it would not be used here anyway.
> > >
> > > From our point of view, this is handled totally transparently by the
> reader
> > > and the smartcard chip.
> > 
> > Manually adjusting max_*_size to some magic value isn't transparent at
> > all. So the question is, why MyEID needs such adjustment whereas other
> > cards don't. You should definitely start investigating that issue.
> 
> Yes, I agree that this is something that we would not want to do, but we are
> stuck with it for the moment.
> 
> My questions are:
>  - have other OpenSC users tried cards that use T=1 protocol?

CardOS and E-Token were very popular in the past. These are T=1 only
devices too (T=0 unsupported): 3B F2 18 00 02 C1 0A 31 FE 58 C8 08 74

They work out of the box with SCM SCR-335 readers driven by libccid. No
adjustments required. Extended-APDUs up to 300+X bytes are working.

>  - have somebody managed to use MyEID cards without adjusting the
> configuration?
> 
> > As a short term solution you could provide a list of readers known to
> > work. That would be most valuable for your customers.
> 
> Since we have only encountered readers that require the configuration tweak,
> we have decided to add the information on how to change the configuration to
> the wiki page.
> Hope this can be solved somehow in the future.

Just a guess:

Quotation from Java Card (TM) Platform, Version 2.2.1:
"The incoming APDU data size may be bigger than the APDU buffer size and may
therefore need to be read in portions by the applet. Similarly, the outgoing
response APDU data size may be bigger than the APDU buffer size and may need
to be written in portions by the applet. The APDU class has methods to
facilitate this."

Regards
Andre

___
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

[Viktor TARASOV]

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.


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

[Peter Stuge]

Jean-Michel Pouré - GOOZE wrote:
> The libccid supported list is for companies which pay technical review.
> When companies do not pay, readers are listed in "Should be supported".

What do you mean by this? It sounds really obnoxious, but I think
there is a language barrier here and I do not want to jump to
conclusions.

I believe that Ludovic keeps the list updated according to testing he
has done himself, as well as input from the community.

Do you have a different understanding?


> Therefore, some companies, are more visible on Internet.

Again, I believe that is because their products behave as expected
and according to specification, and not because they are paying
someone extra money to get special treatment.

But of course it can cost a little more to develop something that is
actually standards compliant.


//Peter
___
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]

Le mercredi 12 janvier 2011 à 23:41 +0100, Peter Stuge a écrit :
> What do you mean by this? It sounds really obnoxious, but I think
> there is a language barrier here and I do not want to jump to
> conclusions. 

Sure, French is my mother tongue, not English. I am a nice guy, always
pleasant with everyone if you know me.

To get listed in the Supported list of libccid, smartcard makers need to
pay for technical review. Because there is some work included for
technical review. I guess there is a lot of work included for Ludovic.

Other companies which don't pay get listed on "Should work" page.

My personal opinion is that I only trust GOOZE and OpenSC users. In the
past I posted several bugs about entersafe driver. Now I am really happy
with the driver. So you can count on me to recognize bugs and publish
them.

As for the R-301-v1 and R-301-v2, I always was VERY HAPPY with the
readers. Event if libccid test suite did not pass, it had no impact on
OpenSC. So I did not care for these pages "supported", "unsupported" and
"should work".

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