KDE and smartcard support

[Alon Bar-Lev]

On 5/23/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > Why not, please please explain.
>
> i already have, as have others. if you are still mystified, just accept it as
> an axiom for now because we, as the current maintainers of kdelibs, have come
> to that conclusion at this time. move on.

I wish I could... we will always return to the same issue. You will
see this next.

> to start at the beginning and show me code, in particular how such hardware
> based auth support might look in KDE's API. i'm not interested in crypto in
> kmail at this point, for instance.
>
> your next email needs to be about that API and include sample code, because
> that is the only productive move at this point. thank you for cooperating and
> making this a fruitful discussion.

Let's discuss TLS session for now, ok?
I will skip the configuration API since it is irrelevant to our
discussion and can be always completed later.

In term of application developer THERE IS NO CHANGE IN CURRENT API.
Surprised?!?!?!

I will try to explain the sequence... And please remember again, I
don't know KDE as well as you.

Take KSSL as base.

Allow accepting NULL at setClientCertificate(). This will instruct
dynamic certificate selection.
Then implement KSSL using QCA.
KSSL will initiate TLS/SSL session, if peer require client certificate
and one was set, it will be offered, if NULL was set, then it will
scan its internal keystores display a dialog for the user to select
the desired one, prompt for passphrase when needed,  prompt for token
insert when needed.

That's it!
You have up and running TLS/SSL session for all KSSL users, using
software based and hardware based cryptography.

Now...
You wish to change KSSL to use QtNetwork, that's find... But the only
change of the API will be move to the new QtNetwork API, that's it.

Is this what you expected?

Of course we can extend the API, and allow explicitly set automatic
certificate selection... :)

I would also like to allow importing PKCS#12 identities into the
configuration, so that certificates will available as none encrypted
during key negotiations so passphrase prompt will be triggered only
for the selected one. (Certificates are encrypted in PKCS#12 format,
and we need to extract the certificate during negotiation without
prompting for passphrase). But this all a configuration issue, and
should have already implemented in current implementation... But this
is usability improvement.

Best Regards,
Alon Bar-Lev.