> Google Chrome is exposing NSS to Java/JSS on Mac OS X? I did not think that > Chrome uses the NSS certificate database at all on Mac OS X.
Google chrome use each OS specific keystore. On OSX its keychain, so theres no need of JSS. In Linux, and using shared nss db, it uses jss and works "well". >> -Does mozilla *WANT* Java use certificates stored on NSS to do document >> signning? >> -What about Java applets? >> -Is mozilla going to *AVOID* Java use certificates, or consider this as an >> "undocumented/undesired behaviour"? >> -What about Java applets? (Still not awswered) > We already expose window.crypto.signText which supposedly will sign documents > using certificates stored in NSS on all *desktop* Firefox versions. This > should be accessible from Java via the Java-JS bridge that I know nothing > about. And, IMHO, this is NOT enough BY FAR to accomplish the bussiness needs. Anyhow, IMVHO, doing different code for different OS/platform is worse (and less portable) than using Java Providers and Java-NSS should be supported >> -Will patches which fix this issues merged (if correct) in branch, or will >> they become marked as WONTFIX? > It depends on whether the bug is in JSS, NSS, Gecko, and what exactly the bug > is, and how complex the patch is. If you provide more details of what doesn't > work, we can discuss whether it is reasonable to try to fix it. Example: https://bugzilla.mozilla.org/show_bug.cgi?id=578751 (This bug fix could solve many of the problems we have with NSS+OSX) > I cannot tell you an official opinion but I would say that I personally would > not bet any money on depending on Java + NSS integration to work reliably in > Firefox, because that would be a very low priority for most Gecko developers. The question can be changed to: -Do mozilla want companies and bussiness to use Firefox? (rather than chrome) -Do mozilla think themes and make up are more important to bussines than this kind of features? > In the long term: > > 1. Write patches that replace the usage of NSS in Firefox with usage of the > system certificate store for client certificates. So, you are "open to stop using NSS", instead od keychain/cryptoapi? Glad to hear :) > 2. Help specify and develop the DOMCrypt JS API in Firefox, including > integration of DOMCrypt with the system certificate store. Going to contact workgroup, but developing a new API (for Firefox only) doesnt solve the problem, just create another one: Support the old+new API. > 3. Rewrite the applet in JS. If you can't, then have your Java application > use the JS<->Java API we have to use the DOMCrypt JS API to sign your > documents. Java was created and designed to be cross-platform. Doing such a thing makes java become a wrapper to "propietary" solutions, instead of making portability a fact. Same for doing a JS for firefox. I prefer option 1. > I noticed that you seem to be considering reading the NSS keyX.db and > certX.db files from Java directly. Not totally correct. I have been "forced" to parse secmod.db, cause Java interface to secmod doesnt seem to work properly (I have to file a few bugs to Oracle) > Keep in mind that it is not supported to access these files directly, that > these files may change format at any time (e.g. Red Hat would like Firefox > and Thunderbird to switch to the SQLite-based format), and that hopefully > Firefox and Thunderbird will eventually stop using these NSS certificate > databases completely except on Linux. None of those things will happen any > time soon, but I expect them all to happen eventually. Again, glad to hear (specially the sqlite part). Why RedHat "would like" -> "mozilla switch"? Thans a lot for your time and pacience, Brian. PS: Thanks Robert for the matthew contact. ;) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
