On Tue, 2014-12-09 at 13:54 +0000, David Woodhouse wrote: > 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 :)
Well, pam_pkcs11.conf states /etc/pki/nssdb by default, however I changed mine to sql: since I figured that "was the new way to go", even if it doesn't matter. I was trying to be consistent since I export NSS_DEFAULT_DB_TYPE globally. I'm aware of the "the new" and "the old" nssdb format, what I don't understand though is why a distribution such as Rhel 7 doesn't default to the new database format (and making sure that every application that used the old now uses the new). But maybe the focus lies on changing from nss to p11-kit, what do I know. > > 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 Great! > 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... :) Well, that's a really good point. Didn't even think of it. But from a user-perspective, I definitely would say that you don't wont to be bothered by unlocking some keyring after I've logged in. Maybe the password for the keyring could be based off your PIN but obscured by some way (security by obscurity). I do though, as said, understand the issue here - when you brought it up =) > > - 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 :) Haha, ok. I get that part. What I don't get is, "why is it there, and when is, and who is suppose to use it" Shouldn't it be removed ? > > /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. I hear you. It seems like we are on the way. From what I understand I think that NetworkManager is also taking that approach, which would be a really good thing. https://wiki.gnome.org/Projects/NetworkManager/PKCS11 > 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... Yes, definitely. Basically all I wanted to do, as stated earlier, was to, "trust our ca, and make 'various user applications' make use of the opensc-module. Turned out to be harder than I thought, but now we are there and I've got a lot more insight in this matter. Again, thanks for all the help and explanations. /Patrik -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
