Hi, On Sunday, 20. May 2012, Peter Koch wrote: > Peter Marshall seems to have written most of the current OpenPGP > driver and Jan Suhr from German Privacy Foundation told me that > Martin Paljak already tried to enhance the driver.
I mostly re-factored card-openpg.c for better extensibility and extended it to also support OpenPGPv2 cards. The basic idea of the otriginal emulation was untouched I aso tried to lay foundations for (maybe very limited) write support, but a) real life took its toll b) I did not get the real idea for thw write support Martin started the extension of pkcs15-openpgp.c to support OpenPGP v2 cards which I continued. (but again: without write support) While I currently don't have an idea for a breakthrough, I'll try to stay up- to-date, adding small fixes where needed (and hoping for genius striking me ;-) > Could you give us some information what the status of OpenPGP > support is right now. See above ;-) > Here are my own impressions - if they are wrong, please correct me: > > 1: OpenPGP cards do NOT have a filesystem like other smart cards. > Instead of storing informations in EFs which are located in DFs an > OpenPGP card stores information in Data Objects. Correct, but card-openpgp.c emulates a file system by treating plain DOs as EFs and constructed (via ASN.1's TLV encoding) as DFs with the ASN.1 label inside as the EFs / DFs in the next level down. Simply try opensc-explorer on an initialized OpenPGPv2 card, and you'll get the idea. > Here my conclusion > is: Without EFs and DFs and in particular without commands to > create EFs and DFs pkcs15-init does not make any sense. Hmm, it depends. While you cannot create real DFs or EFs, I do not consider it impossible to implement write support through the emulation: i.. * for a DO that gets emulated to an EF, it should be possible to detect the write to the EF in the emulation layer and convert this to an DO update * for DFs it might become a bit more tricky. (Maybe this is not needed - needs a very close look at the specs + the right ideas ;-) > 2: The current driver emulates SELECT and READ BINARY APDUs > by reading from the corresponding Data Objects. I believe this > was done in order to emulate a (read only) PKCS#15 file layout. > If that was true - is there any hope to extend this emulation? I'd personally would not hold my breath. But maybe Nguyễn Hồng Quân is the one with that idea that give the breakthrough. > 3: What features are missing in the current implementation and > what bugs should be fixed? I definitely cannot tell, as I do not know what is needed in the PKCS15 and/or PCS11 levels. I consider opensc heaily under-documented w.r.t how everything is tied togeth (this is not specific to opensc alone, but seems to be specific to security related software in general ;-) Best Peter -- Peter Marschall pe...@adpm.de _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
