In the testing process of OpenDNIe I've found a problem related with concurrent access to opensc-pkcs11 library.
In short: as DNIe can only handle one SM at a time (no virtual channel support), there is no (known) way to get concurrent pkcs11 access This "feature" makes unusable most of signing applets commonly used in many official sites Afaik opensc-pkcs11 is thread/process aware, and non-sm based cards can successfully handle "n" processes without any problem noticed. but for DNIe, I need some way to "centralize" all SM task in a single process/thread I'm thinking on a sort of "SM daemon" to take care on apdu encoding/decoding What do you feel on this approach? btw, most of cryptoapplet jarfiles I know can handle access to card by mean of CSP, PKCS#11 and NSS interfaces. Can you confirm me that selecting NSS as interface instead pkcs#11 would solve this problem ? Juan Antonio
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
