KDE and smartcard support

[Alon Bar-Lev]

On 5/23/07, Andreas Aardal Hanssen <ahanssen at trolltech.com> wrote:
> On Wednesday 23 May 2007 11:25, Alon Bar-Lev wrote:
> > ... provided by Trolltech ... If Trolltech will provide cryptography...
> > ...provider that use Trolltech when available... Once Trolltech will ...
>
> [OT] I thought this was about KDE, and Qt, the framework KDE is written in and
> that also serves as QCA's foundation. Why do you keep writing "Trolltech"?
> Can we clear away some steam here, please? This discussion is pointless if
> your intention is to make some strange personal point.

I don't wish to make any personal point.
I just think that an incomplete API should not be used. Just it...
Feeding your API with OpenSSL low level structures in an undocumented
way is not a solution.

But it seems that I am in minority here...

And again, I will repeat my claim, the problem is not with TLS/SSL but
with the whole cryptography approach. And you don't provide a complete
approach in your solution, at least admit that.

Had you implemented the TLS/SSL layer your-self, you would have been
able to say you do something better, but as you and QCA use OpenSSL in
order to do TLS/SSL I don't understand why if we use QCA in
decryption, signature and authentication we should use QtSslSocket to
do TLS/SSL.

> Come on, we all agree cryptographic support is important. KDE needs it. Qt
> provides some, QCA provides some. We can make the two work together, as
> Justin wrote, it's not a big deal. You are giving the impression that you
> want everyone to scrap what they have and start using QCA for everything. You
> even said you want to write a replacement class for QSslSocket. But a few
> mails earlier you wrote:
>
> "I don't wish to start maintaining a critical core KDE component."

I regret I was not too clear about this... As Qt is not core KDE
component, QCA is not.
I don't wish to maintain KIO or KSSL in a way that is different from
current design model.
And as I wrote above, there is not much point in using the current
QSslSocket without looking at the larger picture and see if it gives
any advantage and not add complexity and future incompatibilities.

> Note also that nobody else in this thread seems to be saying "scrap what you
> have, and use XXXX instead". We're saing "here's what we've got, now how do
> we use it". Now please go back and look at Aaron's summary.

I have, and I am sorry you think this is what I am saying.
All I say is that the cryptography should be looked at whole.

BTW: If you wish to provide a cleaner interface, please implement
sign/decrypt virtual methods to QSslKey class, this will allow using
external key model with your QSslSocket implementation. Also I would
suggest not to separate between the end certificate and its key, so
actually QSslCredentials is a better solution holding whatever is
needed in order to perform authentication.

Best Regards,
Alon Bar-Lev.