On Mon, February 3, 2014 4:30 am, David Woodhouse wrote: > 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.
At the risk of diverging even further from a suitable NSS discussion, I will just say that it is categorically *not* the case that it's fairly easy, as the concepts used in PKCS#11 do not reliably map over well to other cryptographic APIs (CDSA/CSSM, Security.framework, CryptoAPI, CNG). This is already true in Chromium's integration, where we use private (in that they're not upstream, but are open sourced) patches to NSS to avoid having to emulate PKCS#11 tokens. This is especially true when considering the different UI interaction requirements. > > 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. See p11-kit, which was also referenced in the design doc, which Red Hat actively contributes to, and which I think is an increasingly viable solution both for NSS and other applications. This is something we're looking at supporting, even with our migration to OpenSSL, so that whether you're using Firefox or Chromium, things should "just work" if you're using p11-kit. > > 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. Our experience has been that when integrated into the library itself (eg: as NSS has done), it leads for a much poorer experience than when provided by the application (eg: Chromium), even if it does require more work to get there. There's a balance to be struck, for sure, and NSS arguably errs too much on one particular pattern, which is, again, part of our reasoning for believing that the transition to OpenSSL will be more in the benefit of our users and our growing list of needs from an SSL/cryptographic library. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
