Oh... It seems like I was not understood correctly... When I say Application I mean the result behavior for the user. Whether the application is using a middleware to achieve this or implement all by it-self is irrelevant to the end-result.
On Monday 27 November 2006 19:38, Martin Paljak wrote: > > 4. If the user removes the card from one reader and insert it to > > another reader, the application should detect that it is the same > > card, and not prompt the user for credentials again. > > Applications, the ones users are using, should not implement such > low level functionality. Applications should not know that such > things as smartcard readers exist at all (again - not all > applications, but the majority of *end-user* applications) True, if they use middleware... But the requirement still stands, look at it as QA requirement. > http://developer.apple.com/security/cdsaopenssl.html helps as well. > Basically operating systems should provide something that > applications can build upon (CDSA on mac, cryptoapi on windows, > upcoming QT thing on linux etc) and the only thing we should do is > to make sure that the given operating system services are good > enough and that opensc or other smartcard 'middleware' can > integrate nicely with the platform management system available > (tokend on mac is a good example :)) Well... I think Microsoft CryptoAPI lacks many features required for low level processing, like FORMAL way to know when smartcard is inserted, a way to enumerate objects on card, use of symmetric keys on external device, store previous (expired) certificates, data objects and more. > What I mean - we can't solve it all in applications, we only solve > it partially if we link all applications to a library, and in the > end - I still believe that pkcs#11 is a bad thing to expose to the > random joe out there. My father would never buy it. True, but unlike OpenSC API which is not standard, and CryptoAPI which misses functionality, PKCS#11 is good enough. I agree that it should not be exposed to end-users, and it is quite complex, so I've written the pkcs11-helper to help. Since PKCS#11 modules exists on *nix, win32, MacOS, I think that PKCS#11 enabled application has advantage over other interfaces. > Do you know about the 'pkcs11 directory' initiative by CAcert > people? http://wiki.cacert.org/wiki/Pkcs11TaskForce Yes. But this lacks the criteria I am talking about. I cannot say Mozilla *PKCS#11 CERTIFIED*... Since the end-user does not get what he expects. > Application developers should get a new level of understanding of > what the heck are keys and certificates and how should you approach > the field so that things like smartcards and keypads and so on > could be introduced with no modifications in their software. When > done right, an application could use smartcards, PCI cyrpto > accelerators and software keys all the same way - even if the HSM > interface is not pkcs11.... Well... You will have to implement a new middleware for this one, I just think it is easier to implement PKCS#11 provider for devices, than creating this generic middleware. > Anyway... great work on the pkcs11-helper thing and welcome! Thanks! Best Regards, Alon Bar-Lev. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
