On Tue, 2014-12-09 at 14:18 +0000, Martinsson Patrik wrote: > 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).
The problem is that NSS-based applications are wildly uncoordinated. As discussed in my response to Bob earlier, even the "in-house" apps like Firefox and Thunderbird are doing entirely the wrong thing. There have been bugs filed for years, and there seems to be very little prospect of them getting fixed any time soon. It *would* be good if a progressive distribution would do a bombing run on applications and fix them all to Do The Right Thing. If we can just agree on precisely what that is :) > > Using the PIN *alone* as the encryption key for your secrets is a *BAD* > > idea. > > 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 =) You have a key on the smartcard. Use *that* to decrypt the 'session' key that's actually used to decrypt the storage. This is now https://bugzilla.gnome.org/show_bug.cgi?id=741247 It's basically the same problem as "I am logging in using a network password, and the password might change on the network". The hooks that GNOME keyring has into the PAM stack work fine for handling the case of a *local* password, when you change that password locally using passwd(8). Other use cases need a little more love. > > 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 > > 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 ? No, because we are moving in the direction where it *will* be used. As soon as we've consistently got all applications *using* the modules that p11-kit has configured, people want to discourage the use of *files* for certificates and keys, and instead have them stored in the GNOME keyring "soft token". It's tied in with the NetworkManager PKCS#11 support that you mentioned. But we aren't there yet, which is why you can disable it for now without worrying. > 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. Right. The "trust our CA" bit is at least fairly much fixed. The work which has already been done with p11-kit-trust and making sure p11-kit-trust is *used* in all applications, has paid off. Getting applications to consistently benefit from the p11-kit configuration for which PKCS#11 modules to use is still a work in progress, as you've found... -- 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
