On Mon, 2014-02-03 at 12:13 +0000, Alan Braggins wrote: > > Having support for PKCS#11 tokens at all is a pro, even if one > irrelevant to the vast majority of users.
That gets less true as we start to use PKCS#11 a little more. It isn't *just* about hardware tokens — things like gnome-keyring offer themselves as a PKCS#11 token, giving you a consistent certificate store which is automatically unlocked when you log in, etc. Integration with key stores on other operating systems is also fairly easy if you have a PKCS#11 interface to them. And it isn't just about keys either — we are starting to use it to get a coherent set of trusted certificates system-wide. Which has historically been a real PITA on Linux with a different set of trusted certs per crypto library, or even per application. Hell, even *Firefox* isn't properly using the NSS "Shared System Database" setup, and stupidly persists in having its *own* separate store. Fedora 19 starts to make sense of this and exports the trust database to a flat file for compatibility with OpenSSL, but it's not ideal and still only addresses *certs*, not keys. There is a middle ground between having decent PKCS#11 support where you can identify a key/cert by a PKCS#11 URL and everything Just Works™ without jumping through hoops, and having PKCS#11 insinuate itself into *everything* as NSS has done. I think GnuTLS has the balance about right, and probably would have been a good choice — if it wasn't for the GPL allergy, although I note GnuTLS has at least switched back to LGPL2.1 in the latest releases. For OpenSSL to become viable, it's going to need a whole lot more than ENGINE_PKCS11. -- 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