Martin Paljak wrote: > On Mar 9, 2010, at 14:44 , Viktor TARASOV wrote: > >> Hi, >> >> it seems that the internal API 'framework' of the pkcs11 module can be >> simplified and be made more flexible >> for the pkcs11 framework level. >> >> My initial motivation is to give the access to the 'sc_pkcs11_slot' inside >> the framework operation 'login'. >> >> And so I would like to change its prototype from >> CK_RV (*login)(struct sc_pkcs11_card *, void *, CK_USER_TYPE, >> CK_CHAR_PTR, CK_ULONG); >> to >> CK_RV (*login)(struct sc_pkcs11_slot *, CK_USER_TYPE, CK_CHAR_PTR, >> CK_ULONG); >> >> >> With that the actual call of this procedure: >> framework->login(slot->card, slot->fw_data, userType, pPin, ulPinLen); >> will change to: >> framework->login(slot, userType, pPin, ulPinLen); >> >> >> The same can be done for the other framework procedures 'logout', >> 'create_object', 'gen_keypair', ... >> > > > What about getting rid of the "pkcs11 framework framework" altogether? I see > PKCS#11 as an "application" on top of libopensc, just like BaseCSP/cardmod > and Tokend. > > As the pkcs11 framework thing is 100% internal, changing it however needed is > always OK for me. > I can imagine building another PKCS#11 interface for non-fielsystem cards > (like muscle applet) directly as a "pkcs11 framework plugin" but having it > around just because of this air thin possibility is not worth it, IMHO. >
Agree. It seems that Andreas proposed to get rid of multi-framework and 'framework-pkcs15init' -- it can be done on the same wave. We'll be thinking about, for a while I limit myself by the little makeup of the 'login' procedure . Kind wishes, Viktor. -- 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
