softoken also isn't a complete implementation of a PKCS#11 module. It's "just good enough" to be used by NSS, not good enough to be used by other PKCS#11 platforms. It's disturbing that it's never been completed. It's more disturbing because the keys I might have in FIPS softoken can't be used in other PKCS#11 apps which might require FIPS conformance, thus mandating either a) multiple keys simultaneously certified for the same Subject in a FIPS environment or b) the same key stored in multiple containers.
This is one of many reasons why I have given up on Mozilla as having anything to do with "security" and everything to do with "noninteroperability". I told Brian Smith that I can't code, particularly in C. I never told him the reason, as it's HIPAA-covered and I don't want my health to be a factor. I'm very, very slowly recovering. That doesn't mean that I'm incapable of seeing the actual long-term consequences of so many of the engineering decisions that on the face of it looked right but digging deeper simply cause a lack of both interoperability and utility. Frankly, I'd rather trust a non-monolithic, interoperable keystore with nonintegrated cryptographic implementation than NSS softoken. I'm glad Chrome is moving away from it to let it die the inglorious death its bullheaded designers created for it. -Kyle H On Jan 31, 2014 10:29 AM, "Ryan Sleevi" <ryan-mozdevtechcry...@sleevi.com> wrote: > On Fri, January 31, 2014 9:18 am, Alan Braggins wrote: > > On 31/01/14 10:24, Julien Pierre wrote: > > > > > > On 1/27/2014 10:28, Kathleen Wilson wrote: > > >> Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from > > >> NSS to OpenSSL: > > >> > > >> > https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 > > > > > Strange that "PKCS#11 support" is listed as a "con" for NSS . > > > > It is at least listed under "pro" as well.... (Having ENGINE_pkcs11 > > listed under both for OpenSSL might make sense too.) > > > > It was not accidental that it was listed under "Con", nor do I see > ENGINE_pkcs11 as a "Pro" > > As part of its fundamental design, NSS performs all operations using > PKCS#11 tokens. Even the internal cryptographic implementation is exposed > as a PKCS#11 token - softoken. > > I realize that from a design and layering perspective, there are those > (especially within NSS developers) that feel this is a Pro. However, in > practical terms, this works out as a significant negative for performance. > It's not "merely" the function call overhead, but the abstraction prevents > significant compiler optimizations for space and size. > > Further, the PKCS#11 API itself - while suitable for interacting with IO > contrained hardware tokens - is absolutely horrible for maximizing CPU > thoroughput. > > Consider AES-GCM or AES-CBC-PAD. The former requires establishing a new > PKCS#11 context every time, which forces levels of key expansion. I > realize some NSS developers have suggested possible ways to improve this - > but the engineering effort is recognized to be complex. We've also been > committed to the newly-formed OASIS TC to try to improve things, but the > reality is that the current spec is "broken for purpose". > > Or consider AES-CBC-PAD, which is essentially *the same issue*. Because of > this, NSS's SSL layer only uses AES-CBC, and handles padding manually, so > that it can keep a single context around for the duration of the SSL > session. > > On the server side, NSS is virtually non-existent on any platform that > deeply cares about performance because of this. Heck, there is a whole > "PKCS#11 bypass" mode precisely for this. > > This reliance on PKCS#11 means that there are non-trivial overheads when > doing something as "simple" as hashing with SHA-1. For something that is > such a "simple" transformation, multiple locks must be acquired and the > entire NSS internals may *block* if using NSS on multiple threads, in > order to prevent any issues with PKCS#11's threading design. > > I tried not to write too much on the negatives of NSS or OpenSSL, because > both are worthy of long rants, but I'm surprised to hear anyone who has > worked at length with PKCS#11 - like Oracle has (and Sun before) - would > be particularly praising it. > > It's good for interop with smart cards. That's about it. > > Cheers, > Ryan > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
