KDE and smartcard support

[Alon Bar-Lev]

On 5/22/07, George Staikos <staikos at kde.org> wrote:
>    I think you are the one who is confused now.  You are welcome to
> use QCA for any of those.  However, SSL policy has been centralized
> in KDE and should be handled through the centralized system.  KIO
> also has built-in SSL protocol support which works, and without any
> additional dependency we can move to using QtSslSocket there, which I
> think is a good thing.  Your smartcard implementation could easily be
> done by providing an abstract interface in kdelibs and then
> implementing it elsewhere.  This is part of what we realized when we
> started writing smartcard code for KDE 7 years ago (and abandoned it
> due to lack of interest and support).

Hello George,

I do not believe that I am confused.

Smartcards is not a separate implementation, it should be available at
any cryptographic operation in the framework. This should be
transparent to applications.

If KDE offers TLS/SSL operations via a specific interface, such as
"KIO", the KIO should provide this service for software and hardware
based cryptography.

If KIO will use QtSslSocket it won't be able to support to hardware
cryptography. And then application will be forced to use another
interface for TLS session with smartcard authentication.

For example konqueror will have to use interface A to establish TLS
session, then if authentication requires hardware cryptography, it
should disconnect the session and use interface B to restablish
session to have it work with the hardware cryptography. This does not
sounds right to me.

I am not sure where kdelibs can be used in order to solve this issue,
but I am sure the proper solution will be to consider each
cryptography API you use and see if hardware cryptography can be used.

I regret that 7 years ago you could not make it work, but now it can
be implement as QCA provide this service and we are committed into
this.

Best Regards,
Alon Bar-Lev.