On 11/19/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
shall we file a bug so we don't forget?
maybe keep track somewhere (new wiki page?) of things we want to do once
we break ABI, so we do those all at once? debug cleanup would be one,
maybe reorganize header files for internal/external s
Nils Larsch wrote:
this is not problem as get_response() can read less, the code in
apdu.c should try to call get_response() until everything is read.
Does the attached patch help ?
yes, thanks.
PS: Perhaps we should put max_recv_size in sc_reader_t as this is
a property of the reader ..
On 15/11/06, Ludovic Rousseau <[EMAIL PROTECTED]> wrote:
On 14/11/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> does it expose this to opensc, so we can set max_recv/send_size
> accordingly?
No. But I can do that.
As I said in a previous message, the CCID driver can expose this
reader li
On 14/11/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
ludovic: does pcsc know about the limitation of the ccid readers?
No.
does it expose this to opensc, so we can set max_recv/send_size
accordingly?
No. But I can do that.
As I said in a previous message, the CCID driver can expose
Andreas Jellinghaus wrote:
Nils Larsch wrote:
the code in apdu.c should do this automatically unless you explicitly
disable this (but perhaps it would be useful if the iso get_response
implementation would respect the reader limits).
that code doesn't look at max_send/recv_size. if the card te
Nils Larsch wrote:
the code in apdu.c should do this automatically unless you explicitly
disable this (but perhaps it would be useful if the iso get_response
implementation would respect the reader limits).
that code doesn't look at max_send/recv_size. if the card tells us
it has 256 bytes, the
Andreas Jellinghaus wrote:
...
also I wonder:
2048bit signatures with cryptoflex 32k cards in scm readers -
they won't work with ccid + pcscd + opensc either, correct?
i.e. we need to implement get response in several small steps
for cryptoflex?
the code in apdu.c should do this automatically u
Ludovic Rousseau wrote:
btw: what exactly is ICCD?
CCID = Chip/Smart Card Interface Devices
I know CCID. but there is also ICCD:
http://www.usb.org/developers/devclass_docs#approved
Smart Card Class
Smart Card CCID version 1.1
Smart Card ICCD version 1.0
If I understand things right, CCI
Douglas E. Engert wrote:
Can the SC_APDU_FLAGS_CHAINING be used to do this?
In the piv_general_io routine in card-piv.c I have a large buffer,
and set the resp.le = max_recv_size (256 for the PIV), but
resp.resplen = buffer size, that is greater the max_recv_size.
I don't think so, the code is
Andreas Jellinghaus wrote:
Ludovic Rousseau wrote:
Can you give me the extract of the CCID specs that says 271 is the
minimal length?
ok, didn't read the part about extended apdu.
btw: what exactly is ICCD?
also I wonder:
2048bit signatures with cryptoflex 32k cards in scm readers -
they
On 14/11/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
Ludovic Rousseau wrote:
> Can you give me the extract of the CCID specs that says 271 is the
> minimal length?
ok, didn't read the part about extended apdu.
btw: what exactly is ICCD?
CCID = Chip/Smart Card Interface Devices
also I
Chaskiel M Grundman wrote:
I do not think cryptoflex supports T=1. certainly, its ATR does not
suggest that:
ouch. should have checked he atr myself.
Where did you get the idea that it does?
crpytoflex programmers manual v4.5 page xxi
"communication protocols: ISO T=0, T=1"
Andreas
Ludovic Rousseau wrote:
Can you give me the extract of the CCID specs that says 271 is the
minimal length?
ok, didn't read the part about extended apdu.
btw: what exactly is ICCD?
also I wonder:
2048bit signatures with cryptoflex 32k cards in scm readers -
they won't work with ccid + pcscd + o
On 13/11/06, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
I had a look at CCID spec 1.10 and - not sure - it seems this is no
longer valid, dwMaxCCIDMessagelength has to be at least 271 bytes
(and max 65544+10 bytes). but that doesn't help, it would be nice
to get the hardware to work.
Can yo
Hmmm. forgot to respond to this part in my earlier mail.
--On Monday, November 13, 2006 11:56:13 PM +0100 Andreas Jellinghaus
<[EMAIL PROTECTED]> wrote:
so if t=1 shouldn't be a problem and cryptoflex does both
t=0 and t=1 I think
I do not think cryptoflex supports T=1. certainly, its ATR does
Chaskiel M Grundman wrote:
--On Monday, November 13, 2006 11:20:11 PM +0100 Andreas Jellinghaus
<[EMAIL PROTECTED]> wrote:
currently ignore the first line,
as we don't select t=1 for cards that can do it, and thus run into
problems.
The only case that openct (in ifd_protocol_select) won't us
--On Monday, November 13, 2006 11:20:11 PM +0100 Andreas Jellinghaus
<[EMAIL PROTECTED]> wrote:
currently ignore the first line,
as we don't select t=1 for cards that can do it, and thus run into
problems.
The only case that openct (in ifd_protocol_select) won't use T=1 is if the
default pro
sorry guys, I realize I know a lot less than I should know about all
these subjects, so as a result I'm still very confused.
the start of my discussion with chaskiel was this
> the scmscr3320 and hp-keyboard appear to have dwMaxCCIDMessageLength
> less than 271 bytes. They therefore fail to proc
18 matches
Mail list logo
