Update on KIO & KSSL

[Justin Karneges]

On Thursday 20 September 2007 3:31 pm, Thiago Macieira wrote:
> Brad Hards wrote:
> >On Wednesday 05 September 2007 07:50, Thiago Macieira wrote:
> >> Brad Hards wrote:
> >> >On Wednesday 05 September 2007 01:57, Eike Hein wrote:
> >> >> Allen Winter wrote:
> >> >> > This is becoming a major impediment to further progress on KMail.
> >> >>
> >> >> Konversation porting is eventually going to run into
> >> >> this as well, FWIW.
> >> >
> >> >Do you need something that QCA::TLS doesn't provide? If you can tell
> >> > me what it is, we can look at it for you.
> >>
> >> Yes: we need integration with KDE's policies and certificate
> >> management.
> >
> >Do you mean (at least) that QCA should provide certs to the application
> > from the KDE cert store (according to the KDE rules for which certs are
> > trusted / untrusted) when that QCA app is running on the KDE desktop?
>
> Yes. It also should do the same checks for verification and the same
> cipher settings. This includes accepting certificates that the user has
> already approved in KDE, even if they fail normal verification.

QCA::TLS doesn't enforce any policies on its own.  QCA is at least aware of 
one policy, which is what root certificates to trust, but even then it is up 
to the application to enable it.  In this way, QCA::TLS is not a whole lot 
different from QSslSocket or even just plain old openssl.  Each are general 
purpose TLS interfaces that push the policy decision burden up to the 
application.

That said, it is possible to extend QCA with plugins.  Policy control via 
plugins is rather limited today, but the API could be expanded as needed and 
I'm open to discussion.  What I'm most concerned about with this approach is 
the impact it would have on applications that expect to have their own 
control over policies (keep in mind that as a pure-Qt shared library, QCA may 
be used by non-KDE applications).

For now, I think the most straightforward way to introduce policies to 
QCA::TLS would just be to wrap it and then have applications use the wrapper.  
You'll be able to trust certs however you like, control the ciphers, provide 
a GUI, and project a minimized TLS interface to the application.  Of course, 
you could wrap QSslSocket or openssl and get the same effect.  Therefore, I 
think the question is not about what QCA::TLS can do.  The question is: who 
will write the above wrapper?

-Justin