KDE and smartcard support

[Alon Bar-Lev]

On 5/23/07, Andreas Aardal Hanssen <ahanssen at trolltech.com> wrote:
> On Wednesday 23 May 2007 13:18, Justin Karneges wrote:
> > 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.
>
> Hm, if QCA can import and export DER or PEM ASN1 encoding, I actually think
> _that_ glue is already in place...
>
> --
> Andreas Aardal Hanssen / bibr - andreas . hanssen @ trolltech.com

What?!?
How?
Do you remember that the subject is SMARTCARDS integration?!?!
How are DER/PEM relate to this?

Before you feel offended again, please review the whole thread, and
realize that your current implementation cannot be used to support the
requirements. After you do, we can start discussion of the real issues
and the way to progress.

Few technicals:
1. You implemented PKI objects only for the purpose of TLS/SSL, which
is wrong way to look at public key cryptography.
2. You did not implement pure virtual (interfaces) for the core
objects, so your implementation cannot work with external
implementation.
3. Your private key implementation lacks support for external private
key operations, so hardware cryptography cannot be implemented at all.
4. You tied TLS/SSL with communication socket, so that you the TLS/SSL
logic cannot be used in other implementations, such as authentication
(802.11X) or POP3/SMTP STARTTLS command.
5. I guess you have also issues with multiple CN/OU/whatever in subject name.
6. What about certificate verification? (CRL, CTL, OCSP), or you wish
the developer to still implement this using OpenSSL code?

I guess there are more...

Please don't be offended... These are pure facts. I guess I would be
more understandable of this lack of design, if this was developed by
volunteers and not a company that sells this. But I don't believe it
is of KDE users' best interest if this implementation will be used in
KDE.

I will be glad to hear that you have a roadmap to solve all these
issues. But even if you do, we would have to work very hard in order
to wrap this in a usable library that provide software and hardware
cryptography.

Alon.