KDE and smartcard support
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
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