As I mentioned in my last post, NIST issued FIPS 140-2 Level 1certificates for NSS. I'm pleased to announce that NIST has just issued the Level 2 certificate. You can see the notification here.

We feel that a Level 2 validation better represents the way our customers deploy NSS-based applications. For example, Level 2 testing allows us to run on a multi-user OS, in multi-user mode, whereas Level 1 requires that tests be conducted with a single user on the machine (which isn't how our customers deploy NSS-based apps). Level 2 testing is also performed on an operating system that "is evaluated at the CC [Common Criteria] evaluation assurance level EAL2 (or higher)".

Level 2 certificates for software are rare. And to the best of my knowledge, NSS is still the only open source crypto library to obtain a Level 2 certificate (the highest available for software modules).

This Level 2 certificate is a big win for the NSS team. Thanks to eveyone who helped!

NIST has issued the FIPS 140-2 Level 1 certificate for NSS 3.11.4.  You can see the certificate here. We expect the Level 2 certificate (currently the highest level possible for software) within a few weeks.  Although Level 1 validation is sufficient for most purposes, we feel that the requirements of Level 2 better reflect the way customers deploy security-enabled products, so we go to the added time and expense to achieve that higher level validation. 

This is the fourth FIPS validation for the NSS crypto libraries.

What does this really mean? 

First, we use this version of NSS in Firefox 2.x.  People who work in the U.S. Federal Government generally must use products that have obtained FIPS 140 certificates (when those products use cryptography).  Now that Firefox is using a FIPS 140-validated version of NSS, Government users can upgrade from Netscape Communicator (yes, you read that correctly) to Firefox 2.0. 

Second, RHEL 5.0 ships with this version of NSS as a shared library.  Apps like RHEL smartcard login, Firefox, and Thunderbird use this shared library and are able to inherit this newly issued FIPS 140 validation.  Further, we're embarking on an effort to NSS-enable a number of key applications in Linux (OpenSSH, stunnel, pam_pkcs11, etc.) to extend the reach of this validation.

Those of you who track this sort of thing in detail will want to understand this next point.  What we submitted to NIST for validation was not all of NSS.  Instead, we put all the code that was subject to FIPS 140 guidelines into a shared library module called the "Soft Token" (/usr/lib/libsoftokn3.so on RHEL). We very cleverly numbered the Soft Token module we submitted to NIST to be version "3.11.4".  So here's the confusing part:  "NSS 3.11.4" includes "Soft Token 3.11.4".  "NSS 3.11.5" and "NSS 3.11.7" also include "Soft Token 3.11.4". So it's not really correct to talk about NSS 3.11.4 being FIPS validated since NIST actually reviewed Soft Token 3.11.4. In hindsight, we should have started the Soft Token numbering with 1.0, and submitted "NSS Soft Token 1.0" to NIST.  Live and learn...

I'll update my blog when the Level 2 certificate shows up on the NIST web site.

Good news: NIST has moved NSS from the "Coordination" stage into the "Finalization" stage! This is, as the name would imply, the final stage on our quest to obtain our fourth set of FIPS 140 certificates.

I'll post again when we have the final certificates.

I'm pleased to announce that the nightly Firefox 3 builds now contain the Camellia cipher. The Camellia cipher was developed by researchers at NTT and Mitsubishi Electric Corporation. We expect that Camellia will be big in Japan in the coming years, and when Firefox 3 is released it will be ready to go. (At this point only developers and testers should be running Firefox 3 builds.)

We don't normally add new encryption technologies to Firefox, so this addition is rather special. In the encryption world, new is bad. Older is better. Ciphers that have been reviewed, deployed, and attacked repeatedly (and survived!) are best. To give you an idea of how rarely we add ciphers, the last symmetric cipher we added was AES in 2002.

Camellia also represents a great open source partnership. The Camellia team went to great lengths to publish their technology and to seek reviews. They provide royalty-free licenses to their patents. They worked through the IETF process to create RFCs for the TLS, IPSec, and CMS protocols. They wrote code to implement the cipher. They contributed this code to the NSS crypto libraries under the standard Mozilla tri-license. We were then able to incorporate Camellia into NSS, and then activate it in Firefox. That process took them years of hard work and diplomacy.

I am very impressed at how well the Camellia team was able to work through all these matters leading up to today's announcement. They have been a pleasure to work with! I look forward to more Firefox uptake in Japan as a result.

If you are running the nightly Firefox 3 builds, you can visit the Camellia test server and check the cipher you negotiated (Page Info): https://info.isl.ntt.co.jp/crypt/eng/camellia/index.html

Here is the bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=382223

Here is the Wikipedia article: http://en.wikipedia.org/wiki/Camellia_(cipher)

As I've written before, we are working to renew the FIPS 140 validation of the NSS crypto libraries.  As of last week, we are now in the "Coordination" phase with NIST.  In this phase, NIST will ask questions about our documentation, and we will attempt to answer them to their satisfaction.

The next and final phase is called "Finalization".  Let's hope the "Coordination" phase goes smoothly!

Brian Forte wrote an article on good documentation, and he uses Fortitude (Apache/Tomcat using the NSS crypto libraries) docs as an example.

I mentioned in November that the fourth FIPS 140 validation for the NSS crypto libraries was moving along. At that time it moved from "IUT" (Implementation Under Test) to "Pending Review". 

The most recent Pre-Validation List from NIST [PDF] shows that NSS has recently moved from "Pending Review" to "In Review". That status means that reviewers have been assigned to the NSS case. (You can read more about the various stages here.) This is a big step forward, and we hope the process will continue uneventfully.

While I'm thinking about FIPS 140, I should mention that Wan-Teh Chang, one of the NSS engineers, will be delivering a talk titled "The Joy of FIPS 140-2 Validation" at the RSA Conference in February.  If you are going to the RSA Conference, be sure to check out Wan-Teh's talk!

The NSS team has been preparing to submit the latest version of NSS for FIPS 140-2 validation at Security Levels 1 and 2.  We completed the necessary documentation, passed the conformance testing, and submitted our docs to NIST last week.  This week, NIST "pre-validation list" (Page 8 of the PDF) shows that NSS moved from "IUT" (Implementation Under Test) to "Pending Review". That means that the ball is in NIST's court, and they may take up to 3 months to issue the final validation certificates.

When the certificates are issued, it will be the fourth FIPS validation for NSS, the first being way back in 1997.

The recent version of the NSS crypto libraries that are undergoing FIPS 140 validation (for the fourth time since 1997!) are now listed on NIST's "FIPS 140-1 and FIPS 140-2 Pre-validation List " page. This is an important milestone on the path to obtaining FIPS 140-2 validation. 

You can learn more about the NSS FIPS effort here:

• http://www.mozilla.org/projects/security/pki/nss/fips/
• http://wiki.mozilla.org/FIPS_Validation

The times are changing for the cryptography in your browser.

As many of you know, the SSL2 protocol has been superseded by the SSL3 protocol, and the TLS 1.0 and 1.1 protocols. As a result, we're working to remove the SSL2 protocol from the Mozilla clients. We'll be able to send the SSL3 hello message to the server when starting an SSL connection. The SSL3 hello will allow us to support a new type of cryptography, called Elliptic Curve Cryptography (ECC). It will also allow us to support Server Name Indication (SNI). [See this page for more information.]

Also, a number of ciphersuites with short (weak) key lengths (40-bits and 56-bits) have fallen out of vogue. They are just too weak to be trusted. So we're working to turn them off as well.

Microsoft is working on the same goals. Here is one of their blogs:
http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx

Here is the page we're using to track the few remaining SSL2-only sites that matter:
http://wiki.mozilla.org/Necko:SSL_v2_Sites

And here is Gerv's blog on the same subject:
http://weblogs.mozillazine.org/gerv/archives/2005/09/ssl2_must_die.html

If you run a web site that uses only SSL2, or one that only uses weak ciphers, it's time for you to upgrade your site!

As an aside, we're continuing to work on "mod_nss", an Apache web server module that allows administrators to use the NSS crypto libraries rather than OpenSSL. See here for more information:
http://directory.fedora.redhat.com/wiki/Mod_nss