On Mar 24, 2010, at 14:29 , Martin Vogt wrote: >>> I don't know what is needed for a possible inclusion in opensc, >>> but in the future this may be an option, if anyone is interested >>> in this. >>> (At this point, it's only a snapshot of my development tree.) >> I think the first requirement would be to have a possibility to expose >> something (a > key or a PIN) via PKCS#11 or pkcs15-tool --dump. > > Yes. this works. (I meant with "reading support" that -D works) OK. Just to verify: the driver successfully exposes keys and PINs on the card via pcks15-tool --dump and the keys can be successfully used for example with Firefox for SSL authentication?
Just wanted to make sure that the read support was on a meaningful level (nut just filesystem read support for select file/read binary). > >> >> If the card is available from a public source in quantities <=10 (a web >> shop) so that > anyone interested could buy it, there should be no >> restrictions other than readable > and functioning code. > I'm unsure about that. I got my card, which has a a pkcs15 struct on it > and a card which is now empty again :-) (for testing the write support.) > But a bit of googleing did not show a web shop where I can buy it. > (But this does not mean, that you cannot buy the cards, I simply havent > found a shop) As a general rule, unless there exists a well known webshop selling the cards, it is extremely difficult to a) get in touch with vendors b) buy small quantities of cards (without a promise of a multi-thousand deal afterwards). Which basically renders many modern cards as unavailable for the general consumer market. Maybe you can ask your source for more information or maybe you can channel cards to other interested people (developers) Why it matters? If the only option is to blindly put the code into OpenSC then there really needs to be a link to an active maintainer or at least somebody who can test whatever changes or investigate whatever issues might pop to mailing list or issue tracker. If you're willing to do it - no problem as long as you remain responsive. But in any case it would be better if there was a possibility to buy the cards without hassle in small quantities. >> Otherwise, for a closed or restricted card, decent documentation on the card >> is >> required and a responsible maintainer contact for the drvier > The documentation is available, as stated in the FAQ: > http://www.opensc-project.org/faq.html (under the starcos section) > (This should be no problem.) If you have not signed a NDA for the documentation? If not, can you share it? >>> If you have a comment ("RFC") what is missing, should be improved >>> etc... please post a reply. >> Some small comments-questions: >> - you seem to have diffed it against 0.11 not trunk. >> sc_ctx_suppress_errors_* is >> long gone for good. > > I tried to diff against trunk, but noticed that the debugging macros changed, > so for now I use the stable release. Also the core API has changed (no slots on reader level for example) > (Is it really necessary to add ~20chars > in every debug call?) IMO not. What would you suggest? Shorter constants? >> - don't use printf in libopensc/* > No problem. Currently its only a development version anyway. If the goal is to keep the version easily mergeable with OpenSC, it would be better to use sc_debug instead. >> - is the card very different from the older starcos 2.3 driver? > > Initially I started with the 2.3 driver, because I thought, its maybe changing > the ATR, fixing some smaller thing etc.., doing after that > some backporting with if/else constructs and then it works. > (Then I noticed that it wont be so easy.) > > I hadn't any knowledge of smartcards and experimented much > with the original 2.3 code, thus there is not much left from it. > In other words, I started with the idea of a patch against 2.3, then I was > forced to do some refactoring, then some more. > Thus, I would say, they differ(in the context that the 2.3 driver needs > a refactoring.) > >> If it would be small and simple, maybe a single starcos driver could do, >> with if-s for >different versions. (have not compared the files yet, just >> asking) > > I had to rework the fci,fcp and in in combination with that the > select_file call, which then needed different cache handling. > Then I worked on the sec_env and because this seemed not to work at > all I experimented a lot with it, which means code rewrite etc... > Although, many apdu calls are still the same, like in the 2.3 driver. OK. Thought so (that it's not that trivial) :) > >> - do you have a manual for the card? > Yes.(But I cannot share it.) Why? Have you signed an NDA or is there something similar that forbids you from doing it? > >> If there is a manual that defines different bits to set, maybe re-create the >> >constants by using bitwise operators instead of having a table of opaque >> constants >(sc_algo2apdu table) > This whole set_security_env is still a mystary, and it would be nice > to have more information in the code where the bits from opensc > go into the apdu call. But I have not found another solution yet > (and I doubt that there is anything possible), like getting the bits > from opensc and then altering matching bits for the apdu. Look for similar code in OpenSC. In such cases having symbolic constants and manual composition of command byte is much better than using cryptic numeric constants. Even though they seem to match very often (like pcsc pinpad code and ccid command blocks) they don't match 1:1 >>> I know, that writing support is missing in the driver, but >>> up to now I haven't figured out how opensc and the pkcs15-init >>> mechanism works...(I think I already locked up one card with >>> writing, so you should definitely not try this) >> True, this is a bit complicated. I hope we can have a small howto for new >> card >drivers one day. I don't know the full story with PKCS#15 >> initialization either, I >guess Viktor might be the best source for this >> information. > > Up to now, I cannot even come up with a question, because I dont know > what to ask :-). OK, good luck. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
