Re: gnome-keyring Seahorse and smart cards (OpenSC) / FOSDEM

[Martin Paljak <martin martinpaljak net>]

Hello,

On Sep 28, 2010, at 5:38 AM, Stef Walter wrote:

>> Some presentations
> 
> Yes, there were several of security presentations at GUADEC. As I posted
> elsewhere, my talk was about PKCS#11 and bringing together an
> infrastructure for usable crypto in GNOME:
> 
> http://memberwebs.com/stef/misc/guadec-usable-crypto.pdf
Interesting.

Some thoughts:
- (Page 8) Why do such separation, PGP and others?
(Open)SSH is not X509 related (but there is patch for this). From my perspective, it could be "X509 (SSL/TLS, S/MIME)" and "Others (PGP, SSH)".
But I'm not that big fan of X509 and related CA business myself.
- (Page 13) Key stores and applications. OpenSSL is growing a store interface in 1.0 and NSS has the Shared DB initiative. 
IMHO It is not the lack of integrated support in OpenSSL or NSS, but lack of interest  and good examples among application writers, who chose to use OpenSSL for their business the way they chose.
IMO there should be a better separation between crypto providers (who provide RSA_SIGN, RSA_DECRYPT etc) and which can be hardware (via PKCS#11) or done in software, as is (re-)implemented by OpenSSL, GnuTLS, NSS.
And there are protocol stacks, built upon crypto providers. Like SSL/TLS is implemented OpenSSL, GnuTLS, NSS, like SSH is implemented by OpenSSH, dropbear etc.
PKCS#11 should not implement SSL and SSL libraries should not implement key and certificate stores. Yes, PKI requires management of public keys or certificates, but requirements for it can vary from application to application.
The requirement to specify CA certificates globally is both good and bad. It would be good in a closed world environment (corporate environment) where there are only two colors, black and white, trusted and untrusted, but a world of trust approach is more close to FOSS world and also has better granularity (SSH authorized_keys file, PGP keys and key signing).
One of the problems could have been bad examples, I guess. It is common input to OpenSSL, a "PEM file with private key", a "password protecting the PEM file" and maybe a "certificate PEM file" and the pattern is copied everywhere.
Applications have no concept of a key store, they are bound at configuration time to a single keypair to operate with.
- (Page 22) You specify both -nodes (don't encrypt private keys) and -des3 (encrypt private keys) option to openssl pkcs12. You could do without a password :)



>> How many people besides the ones listed on the wiki?
> 
> About 15 to 20 at the BOF, I think.
At FOSDEM room sizes start at ~60 people and the organizers told they expect ~4..6k visitors, so "better plan for a lot of people".
Unlike GUADEC, FOSDEM should have mostly developers attending, so the event could be more productive/focused.
At the same time, gathering different people from different projects with slightly different interests and goals poses other challenges for a successful event.



>> I still don't fully understand what Seahorse/GnomeKeyring wants to
>> become (when compared to QCA [6] or OSX Keychain) 
> 
> GnomeKeyring is something like OSX Keychain internals, it stores
> passwords, secrets, keys and certificates.

OK. The way OS X has added smart card support is... "magic".

For OSX, the "path" for accessing smart cards with a GUI for example is Keyring Access.app/Keyring services/CDSA/securityd/pcscd/OpenSC.Tokend,
for Gnome it would be Seahorse/GnomeKeyring/PKCS#11/OpenSC/pcscd ?

Do you know about the activities at freedesktop? [1]


> Seahorse is the key manager for GPG keys, passwords, and certificates
> (via PKCS#11). Seahorse is the UI.
PKCS#11 does not make the best certificate management interface. Certificates (especially CA certificates)
don't require PKCS#11, which is a crypto token interface. Have a look at OS X keychain and the number of tunable trust settings for certificates.
accessing certificates via PKCS#11 makes sense only if the associated private key is present via the same PKCS#11 module or if some
library implements peer related decisions by taking as an input a PKCS#11 slot with certificates and the application knowing beforehand that those certificates
have a certain trait (trusted for an application/activity).

> GnomeKeyring has its focus on common and secure storage of secrets, keys
> and certificates. We haven't tried to make it into a crypto library.
> It's supposed to be useful together with lots of other components
> (including QCA) and bring them together.
> 
> OpenSC creates drivers for smart cards and related infrastructure.
> GnomeKeyring and OpenSC use a lot of the same technologies, and can
> interoperate in various ways.
> 
> A lot of the pieces of the puzzle for all this integration are coming
> together, but there's a lot more polish necessary.
> 
> My presentation at GUADEC had a lot of info about this goal.
> 
> There's so much to do to have a polished and usable linux desktop
> crypto. Even though people have different goals, the 'space' is so big
> that we can work and interact without stepping on each others toes.
Yes. 

> 
>> or how exactly it
>> matches what OpenSC is trying to go, but I'm sure tighter
>> vision-sharing helps to get there faster.
> 
> Yes for sure.
> 
>> There have been a long time idea to organize a meetup of OpenSC
>> developers and the best idea would be to do it at some nice
>> conference. FOSDEM [7] seems to be the perfect candidate. To make the
>> event fruitful, the idea of having a devroom with "Security /
>> hardware crypto keys" . I will not repeat what I wrote on
>> opensc-devel [7], but I'm looking for potential visitors to the event
>> and try to gather a common set of interests and requirements/tangible
>> tasks for a devroom and also ideas for workshops and code sprints and
>> whatnot.
> 
> Very cool. I'd be interested in taking part.
Great!
I read from your presentation that you're in contact with GnuTLS folks. Can you ping them about the meetup at FOSDEM, with a link to the OpenSC wiki? [2]


> BTW, I'd suggest subscribing to the gnome-keyring-list gnome org mailing
> list, as gnome-keyring is where a most of the PKCS#11 action in GNOME
> takes place. Although it's a goal to have seahorse be a good UI and key
> manager for PKCS#11 tokens as well.
Done.

[1] http://lists.freedesktop.org/mailman/listinfo/authentication
[2] http://www.opensc-project.org/opensc/wiki/FOSDEM2011
-- 
@MartinPaljak.net
+3725156495