KDE and smartcard support

[Alon Bar-Lev]

On 5/23/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Wednesday 23 May 2007, Alon Bar-Lev wrote:
>
> > I am looking at QCA as a candidate for this API.
>
> i understand that; i'm hoping you will similarly understand that this is
> simply not on the table right now.

Why not, please please explain.

> one of the big problems here is that while i'm trying to get you back to
> speaking about things in concrete terms, you're speaking in generalities. i'd
> like to see actual API examples.

I really don't understand! And I am not joking with you!

Any cryptographic framework, such as Microsoft CryptoAPI or QCA should
provide the following:

1. Low level cryptographic providers abstraction. This is required in
order to allow device independent implementation. The underline
providers may be software based or hardware based, when talking about
hardware based we have Microsoft CryptoAPI and PKCS#11 interfaces.

2. Low level cryptographic atoms: Encrypt/decrypt/sign/verify.

3. High level cryptographic atoms: PKCS#X, S/MIME, TLS, SSL, X.509

4. Policy enforcement (X.509 CRL, CTL, OCSP)

5. Keystores to hold certificates and keys, dynamically updated by
providers, having events when status is changed.

Trolltech supply no such architecture, providers cannot be used, so
hardware cryptography cannot be established, it does not provide the
atoms, so any other operations except of TLS/SSL cannot be
accomplished, and it does not provide policy enforcement, so the user
ends up in using another cryptography library in parallel.

Moreover, its design shows that it is not going into this direction.

> so let's speak about concrete examples: what would a sample bit of code that
> is performing a crypto operation with smart card authentication look like in
> your mind? remember that it needs to use the KDE facilities for things such
> as the password/token dialog, etc.

QCA is the example, everything there is in QCA we need in order to
implement common cryptography in KDE.

> i'm not interested in the "greater goal" issue here; we can work towards that
> incrementally. start with the issue of smartcard integration, and start that
> with actual examples of API and its usage.

Without greater goal you will never approve the resources required in
order to support this minor smartcard feature into KDE.

So even if you decide to use QtSslSocket, and Trolltech will provide a
documented ability to implement sign and decrypt externally, we still
have to use the other layers of cryptography framework, that means
that QCA should be used anyway.

So I really don't understand what you asking me.

Alon.