[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE and smartcard support
From:       Justin Karneges <justin () affinix ! com>
Date:       2007-05-23 11:18:37
Message-ID: 200705230418.37893.justin () affinix ! com
[Download RAW message or body]

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.

-Justin
[prev in list] [next in list] [prev in thread] [next in thread]