Hello, Le 15/05/2011 02:47, Juan Antonio Martinez a écrit : > I'm unsure about status of last svn changes (r5443,r5442,r5441,r5439, > and r5438) that introduces 'remote data' handling headers and SM related > error codes.
'Remote data' is for the communication with the external SM modules. It's hardly concerns the dnie card. > As r5441 and r5442 inserts and then remove SM support from 'configure' > file, not sure if I can use other SM sent patches, specifically > SM error codes handling. ¿Are they stable? ¿Can I use them in OpenDNIe? SM configure option was removed and commit of SM suspended for the reasons related to the next release. This release has to be accomplished in the nearest days, after this the SM commit will be continued. The SM error codes are stable. You can freely use them and add your own ones. > BTW: there are some SM related APDU responses that aren't included > in iso7816.c file. I can provide you proper patch to add them. Yes, some code are missing, your proper patch are heartily welcome . > If continuing sending patches, please notice some issues from OpenDNIe > I've added to wiki on SM proposal [1]. In wiki you note that your proposals are basically the same > Initialize and load (if required) specific SM module, but only start SM if > card requires to do so That's what I mean when saying 'try to initialize SM from OpenSC configuration'. Use SM or not will be decided by the card driver or by the OpenSC configuration section related to card. > Provide functions for start/stop/testAndSet SM New card member 'SM context' will be added to sc_card structure. There will be the placeholder for the SM related card/exrternal-module handlers, session data, etc. Every one will find the possibility to implement what he looks for -- integrated or external SM handlers, 'transmit' or/and 'acl' modes, CWA or GP protocols, ... > do not wrap/unwrap at do_single_transmit(), but at sc_transmit_apdu() level, > by providing an extra wrap/unwrap card operation. Personally I do not see big difference where to insert the call for the card specific SM encoder handler -- in do_sigle_transmit() or in sc_transmit_apdu() . There already was discussion on this subject and I do not get the answers on the last questions. For me the common procedure contains already the code to manage 61xx, 6Cxx, chaining. If the apdu is deviated to the 'SM wrapping' in sc_transmit_apdu(), it means that all this has to be repeated in the card specific part. Finally there is no interdiction to introduce both handlers and then to see what is more commonly appropriated. > Cards that do not use SM, just leave this card_op as NULL Card that do not use SM will not initialize SM context and, as a consequence, will leave the SM handlers at NULL. > I thought that SM is planned for 0.12.2 [2] and afaik there was no (yet) > consensus on how to implement ... For more then 40 days the discussion about SM had no continuation. The last opinion was "your layout as the most promising". The absence of SM framework handicaps a lot the development, not only of SM itself but also support of 'external authentication' and other ... Let's start from the general SM framework . > Juan Antonio > > [1] https://www.opensc-project.org/opensc/wiki/SecureMessaging > [2] https://www.opensc-project.org/opensc/roadmap > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
