KDE Cryptography Module

[Tom Albers]

Op do 24 mei 2007 00:40 schreef u:
> Tom Albers wrote:
> >Op wo 23 mei 2007 20:37 schreef u:
> >> Mailody is using QSslSocket without any certificate store or policy
> >> management. This is obviously not acceptable for a release.
> >
> >I store them in a database if the user wants that..
> 
> That's not the way it should be. Certificates should be global in KDE. 
> There should be a standardised window saying "here's a new certificate, 
> do you want to accept it"?

That's exactly what i would prefer and use instantly as soon as there is code. QSslSocket is there so people will start using it - even if we decide to only support QCA.  So we if we do the latter, please provide an interface for QSslSocket where people can pass on the received certificate for verification. Delaying it to KDE 4.1 will bring big security risks imho.

 > The CA list should be maintained at a central place.

Yes.

> Applications shouldn't deal with certificates at all. At most, we should 
> provide a UI for each application to choose a certificate and then record 
> that config.

Yes.
 
> >I'll switch to QSslSocket usage directly then.
> 
> No, that's the wrong approach.
> 
> When we bless one alternative in KDE, that's the *only* alternative that 
> will be allowed in KDE code. 

Mailody is not part of the main modules. I've used QCA for the KDE3 releases and implementing TLS/SSL with QCA correctly and for all mailservers is a pain to be honest. I will not switch back to QCA. Unless of course QCA is wrapped in functions identical to QSslSocket.

> If we decide it's QSslSocket, it's that and 
> QCA::TLS or plain sockets are not allowed. Same if we decide to go for 
> QCA::TLS: at that point, QSslSocket is simply not allowed. I don't know 
> if supporting both is possible or even desireable.

'simply not allowed' is a bit harsh. You might mean 'not supported by the KDE security team'.  QSslSocket is simply there.

> It depends on how easy it is to merge the certificate store mechanism with 
> KSSL's current (and probably replace it). Then we start phasing out 
> KSSL's own backend.
> 
> Hopefully, by the second beta (July 25th), we'll have a preliminary API.

Great, I can't wait ;-) I can implement it in Mailody quickly so there is a real test case to work with.

Toma