Re: Seahorse and smart cards (OpenSC) / FOSDEM

[Stef Walter <stefw gnome org>]

On 2010-09-28 01:50, Martin Paljak wrote:
> Some thoughts: - (Page 8) Why do such separation, PGP and others? 
> (Open)SSH is not X509 related (but there is patch for this). 

OpenSSH uses exactly the same key formats as X509 certificates. From a
key storage perspective they're very related.

Although PGP uses some same or similar algorithms, it's the one that's
very different from "all the rest". Of course, I'm painting with a broad
brush here...

 - (Page 13) Key stores and applications. OpenSSL is growing a
> store interface in 1.0 and NSS has the Shared DB initiative. 

Interesting. Do you have any pointers to this stuff.

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

Right. PKCS#11 doesn't implement SSL, but provides foundation blocks for
it. However PKCS#11 does go into providing all sorts of optional
symetric algorithms and mechanisms, many of which are not super useful
from a key storage perspective.

These are in the PKCS#11 standard from a hardware acceleration
perspective. When implementing a PKCS#11 module one typically only
implements the algorithms that are useful to the module, and leaves the
remainder to be implemented by upper level crypto libraries.

That said, there are certain symmetric algorithms that are useful for
hardware crypto providers to implement for things like wrapping keys, etc.

> The requirement to
> specify CA certificates globally is both good and bad. 

Cross certificates are an interesting solution to this problem. But I
hope others emerge. [1]

I'm a firm believer in bringing this stuff into more use in order to
solve the problems. A good example is how Google is enabling SSL on many
of its services. In doing so they've come up with several solutions to
speed up SSL handshakes. [2] Perhaps some of them are flawed, but from
this sort of real world use and research solutions emerge that help us
move forward.

Sitting around talking only gets us so far, implementing stuff and
trying it out helps us get the remainder of the way.

> 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

Yes, this is exactly the problem we're working towards solving.

> (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 :)

Network manager gives a big waring, see screenshot on later page.

> 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 ?

Seahorse accesses PKCS#11 modules directly. Key management goes:

Seahorse -> PKCS#11 -> OpenSC -> pcscd

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

Yes, I'm one of the authors of that spec. It's for password storage. In
GnomeKeyring we implement that spec using PKCS#11 as a layer underneath
the Secret Service DBus API.

>> 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. 

This is implemented via PKCS#11 with the storage trust assertions. NSS
has supported this for a while. In gnome-keyring we've had partial
support for a while, and is growing full support [3].

A formal spec hasn't been defined for trust assertions besides being a
mature method for doing this stuff. I'm working on a specification for
it (very rough stage). [4]

> 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).

Yes, that's what trust assertions allow.

>From gnome-keyring we see PKCS#11 primarily as a key and certificate
storage API. It was chosen because it's widely supported, not because
it's perfect for this usage.

If another key and certificate storage API emerges and has a lot of
backing and effort behind it, I'd certainly join in the fun and get
behind it.

>> 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]

Sure will do.

Cheers,

Stef

[1] Section 4.6: http://www.ietf.org/rfc/rfc2510.txt

[2] for example:
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

[3] http://git.gnome.org/browse/gnome-keyring/log/?h=trust-store

[4] http://thewalter.net/git/cgit.cgi/pkcs11-trust-assertions/