I have been told that some things about my message were not so clear so I will try to clarify them by responding to myself below. In particular, there is some confusion about what has been decided and what is being explored.
Brian Smith wrote: > 1. Create a supported configuration of NSPR+NSS (in the NSS CVS trunk) > that that supports static linking with profile-guided optimization > (PGO)and whole-program optimization (WPO). Wan-Teh has already written > patches to do this for Chrome and those patches have been tweaked by > others at Mozilla. But, we need reviewers for the patches after they > are cleaned up. See [1] and [2]. I think the NSS team has generally agreed to be more open to this idea than we at Mozilla had previously thought. But, the exact approach hasn't been decided on yet: https://bugzilla.mozilla.org/show_bug.cgi?id=534471. > 2. Update the NSS source code (primarily in libssl, Softoken, and > FreeBL) to allow us to exclude dead code sections from the build when > the the compiler's WPO cannot remove them automatically (e.g. libssl's > server-side code code when linked into Firefox, the bypass mode code, > and anything in FreeBL/Softoken that isn't actually used by Firefox). See my summary of the investigation I did into this a couple of weeks ago: https://bugzilla.mozilla.org/show_bug.cgi?id=611781 > 3. Decouple the release of the FIPS-validated Softoken from the > release of the browser. For example, if we need to ship a version > of Firefox that needs some crypto bits that are in a version of > Softoken/FreeBL that hasn't yet been validated, then we will ship > the release with the newer NSS and provide the FIPS-validated > version afterwards. Put another way, FIPS mode issues won't block > Firefox. This is nothing new. I have been told that we've been operating this way since FF 3.0 or 3.5. > 4. Provide a "FIPS mode" option in Firefox wherein the > statically-linked Softoken and FreeBL are disabled in favor of the > use of a dynamically-loaded FIPS-validated PKCS#11 module. If > Softoken is the FIPS-validated module, then NSPR and NSS must > support being loaded multiple times into the same process (once > statically linked, and at least once dynamically linked). > > 5. Add the few missing bits to FreeBL that would be needed to have a > 100% bypass mode (no PKCS#11 usage) in the client part of libssl, and > then remove most/all of the statically-linked copy of Softoken from > Firefox in favor of using the FreeBL interface directly. We would > still support the non-bypass mode specifically for FIPS mode. I have > done some experiments with this and it seems like it doesn't require > much additional code added to FreeBL; I can probably eliminate as much > code as I add. > > 6. Remove the FIPS-validated Softoken from the default Firefox > distribution, and distribute it as part of an add-on. I think there are many things that can be done to reduce any startup time impact caused by Softoken+FreeBL, without resorting to statically linking Softoken+FreeBL and without expanding the usage of the bypass mode. Also, there were many objections especially to #5. If we can avoid statically linking Softoken+FreeBL into libxul then #6 is a non- issue. > 7. Use operating-system APIs for client authentication, so that client > certificates and smart cards are stored and managed by the operating > system's APIs and tools. I know there is a PKCS#11 interface to native > OS interfaces in NSS already, but I think we can provide a better > experience for users by just using the native APIs--and probably do so > with little maintenance cost (in NSS) and notably less overhead. Note > that this means we will never support client authentication with > static ECDH/DH encryption keys; we will only support key exchange > mechanisms where the client has to provide a signature. > > 8. On platforms where we use the system NSS shared libraries, allow a > configuration where the system NSS libraries are used for client > cert/smartcard support while the built-in static NSS is used for > everything else. I think that we should be able to use the native OS facilities without using the PKCS#11 wrapper for them. But, whether we should support the native OS storage in addition to the current Firefox-private PKCS#11 storage is still very much an open question. Note that there are already patches for doing something similar in Chromium's tree. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
