Thanks Douglas, I applied your patch to trunk. Thanks again Mats for reporting the issue and sending the patch.
Regards, Andreas Am Donnerstag 04 Februar 2010 23:44:36 schrieb Douglas E. Engert: > On December 17, Mats Andersson sent in a patch for apdu chaining, > and I responded that this might cause a problem with the card-piv > driver. > > I am attaching a patch that removes the restrictions for card-piv.c > and piv-tool.c. His patch to adpu.c is also included. This patch is > against svn revision 3986, two days ago. > > The patch does: > > adpu.c is Mats' original patch. (The rest of these changes can run > without this.) > > the PIV driver no longer need to set the card max_*_size parameters > to get around emulating read_binary and write_binary. It can > now handle partial reads and writes. > > The assumptions for write_binary are that the first chuck will > have idx = 0, and the last chunk will write the last byte. > The flags parameter will contain the total length. > > The only write_binary operations are done when initializing > a card, and this is only done from piv-tool.c which was modified > to pass in the length and other flags. > > Piv-tool continues to be a primative test tool for inializing test > cards. But it has been expanded to be able to write other objects > on test cards. > > The serial number of a PIV card is obtained from the CHUID object > if present which has a FASC-N which is an ID number created by the > issuer. Normally PIV cards are issued the U.S. Federal government > But there are ways to use the same cards with a non government CA. > This is then be referred to as PIV Compatible. In this case, > the FASC-N should start with an agency code = 9999 and an RFC 4122 > GUID should be present in the CHUID. If this is the case, the GUID > is used as the serial number. > > Windows 7 comes with a PIV card card driver, but to get it use one of > these card the CHUID is required. (piv-tool can now write one. > > For anyone interested in the difference of "PIV Card", "PIV > Interoperability" and "PIV Compatible" see: > http://www.idmanagement.gov/documents/PIV_IO_NonFed_Issuers_May2009.pdf > and also 800-73-3 draft found here: > http://csrc.nist.gov/publications/PubsSPs.html > > Andreas Jellinghaus wrote: > > Mats here has a fix for apdu chaining / the default > > send size is too big. I don't know much about this > > topic, so could you please review this change? > > > > Regards, Andreas > > > > ---------- Weitergeleitete Nachricht ---------- > > > > Betreff: Re: [opensc-devel] OpenSC 0.11.12-rc1 release candidate > > available Datum: Donnerstag 17 Dezember 2009 > > Von: Mats Andersson <ma...@checkpoint.com> > > An: Andreas Jellinghaus <a...@dungeon.inka.de>, Martin Paljak > > <mar...@paljak.pri.ee> > > > > > > Hi again, > > > > Here is the udiff. I think the patch is safe. However, by itself maybe > > this patch is not worth much, it only solves half of the problem that > > this is now hard-coded in opensc (I just did this for keeping copying to > > a minimum when I did support for a vasco-card). > > > > If cards support extended APDU's they don't need chaining typically (this > > patch will only affect sc_transmit_apdu() when SC_APDU_FLAGS_CHAINING is > > set). Anyway, as I said, it would be even more "generic" if one has a > > flag/option on card-level which indicates that the card supports chaining > > (I think it's a discoverable capability of the card according to iso7816, > > I think through ATR inspection). Then change the code so that it will > > "auto-chain" if a larger than max_send_size APDU is to be sent (i.e. when > > extended APDUs are supported the max_send_size is set to the max that can > > be sent with extended APDUs, hence no chaining will take place there > > typically). > > > > I can have a go at such a patch if there is interest. What is the > > official way to provide patches/help out with testing/development? > > > > Cheers, > > > > /Mats > > > > On 12/17/09 5:34 PM, "Andreas Jellinghaus" <a...@dungeon.inka.de> wrote: > > > > Hi Mats, > > > > thanks for your patch, I was not aware we had a problem there. > > > > could you resend your patch in unified diff format ("diff -u")? > > that is much easier to review. > > > > I think however the solution is not as simple as this patch - > > some cards support large APDU commands ("extended" are they > > called I think), so I need to check with the development > > team to make sure we don't fix one and break other cards. > > > > so this patch won't go into 0.11.12, but if we can verify > > it fixes a problem and rule out breaking other cards, we > > can have another 0.11.* release for it. > > > > Regards, Andreas > > > > Scanned by Check Point Total Security Gateway. > > > > > > ------------------------------------------------------------- > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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
