On Tue, 2014-12-09 at 13:15 +0000, Martinsson Patrik wrote: > So, If I don't have opensc-module, one way or another in > (sql):/etc/pki/nssdb I will loose all functionality that gsd brings me, > for example "lock screen at card removal".
Not sql:/etc/pki/nssdb; this is another one that that uses the legacy database format in /etc/pki/nssdb instead. Just to add to the fun :) > If this implementation is wrong and should be done in another way I > cannot answer for. I just know what works and what doesn't. If it's not honouring the p11-kit configuration, then it's broken. I filed https://bugzilla.gnome.org/show_bug.cgi?id=741293 Yes, adding OpenSC (or p11-kit-proxy) to /etc/pki/nssdb/secmod.db will help to work around the problem. > - I've now verified that both the "Login" keyring and the "gnome2 > key storage" gets my PIN as password when logging in the first time. > This is fine, I like this approach. I don't. Your certificate is two-factor authentication — a combination of something you have (the smartcard itself), and something you know (a PIN). Some people might have a trivial PIN such as 123456 on their device on the basis that the PIN is useless without the device itself. Or no PIN at all. Using the PIN *alone* as the encryption key for your secrets (or your whole home directory, in the case of ecryptfs which is going to do something similar) is a *BAD* idea. But we digress... :) > - What is "Gnome2 Key Storage"-kerying anyway, what is it actually used for. > Everything seems > end up in "Login"-keyring anyway ? I'm confused. > > > You didn't actually want to *use* it for PKCS#11 anyway. > > - Isn't there a reason for gnome-kering.module to be a pkcs11 module you mean > ? It's cute that GNOME keyring can provide PKCS#11 functionality and you can store certificates and keys in there. But you aren't *using* that functionality. So just unregister the module entirely by deleting its file from /usr/share/p11-kit/modules/. Then you don't have to worry about its behaviour, or the apps which don't support the protected authentication path. Life's too short :) > /Me is getting more confused for every day that passes ;) Yeah, this stuff is painful, but thanks for helping us work through it. We *really* need to get to a point where all applications in a system will *consistently* use the PKCS#11 modules configured in p11-kit, regardless of which crypto library they're using. And all command-line references to certificates/keys will accept PKCS#11 URLs as well as filenames. Precisely *how* NSS gets there, it doesn't really matter — whether it's adding p11-kit-proxy.so to {sql:,}/etc/pki/nssdb by default and actually making applications *use* that directory (qv.), or by symlinking libnssckbi.so to p11-kit-proxy.so or actually adding proper *native* support for p11-kit for loading the right modules at the right time. With p11-kit-trust we have made great progress — at least we can now have a consistent trust database, maintained by the sysadmin and reliably used by *every* application that needs it. Next we need to sort out the rest of the story... -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
