KDE and smartcard support

Justin Karneges justin at affinix.com
Wed May 23 12:18:37 BST 2007

On Wednesday 23 May 2007 1:53 am, Andreas Aardal Hanssen wrote:
> On Wednesday 23 May 2007 10:11, Justin Karneges wrote:
> > Then, a user could obtain a QCA::PrivateKey object and convert it to a
> > QSslKey object and pass it to QSslSocket.  When your OpenSSL tries to
> > sign with the private key, it will ask the RSA*, which will ask QSslKey,
> > which will ask QCA::PrivateKey, and whatever happens after that doesn't
> > matter. :)
> That sounds reasonable to me. Either we make converters, or plug them
> together somehow. As long as we agree that this isn't about QCA vs.
> QSslSocket; having two APIs that does the same sucks. The issue at hand is
> smart card support, and in that sense providing an SSL socket is
> orthogonal, and quite solvable.

QCA does have an SSL/TLS API as well though, and so in that sense we would 
have two APIs doing similar things.  It would be QSslSocket vs QCA::TLS.  
However, KDE could just have an overall policy of preferring QSslSocket in 
that case.

And yes, an SSL socket is orthogonal to the whole key handling stuff.  Even 
QCA::TLS is pretty well independent from the rest of QCA.  I think it would 
be quite reasonable (from a technical perspective) to be able to use a 
completely different SSL/TLS API, such as QSslSocket, with a private key 
obtained through QCA.

Let me know if you have any questions or alternate suggestions.


More information about the kde-core-devel mailing list