Mozilla Crypto FAQ

In this document I try to answer some frequently asked questions about the Mozilla web browser and mail/news client and its support for SSL, S/MIME, and related features based on cryptographic technology. Note that this document is for your information only and is not intended as legal advice. If you wish to develop and distribute cryptographic software, particularly for commercial sale or distribution, then you should consult an attorney with expertise in the particular laws and regulations that apply in your jurisdiction.

I've updated this version of the Mozilla Crypto FAQ to discuss the situation now that the RSA public key algorithm is in the public domain and a full open source crypto implementation is being added to the Mozilla code base. Information in the FAQ also reflects the new U.S. encryption export regulations published on January 14, 2000, the release on February 11, 2000, of source code for SSL, S/MIME, and general PKI functionality for use in the Mozilla project, and the "Bernstein advisory" issued by the Bureau of Export Administration on February 17, 2000.

The questions in this FAQ address Mozilla's support for encryption and related security functionality, information important to Mozilla contributors relating to encryption functionality in Mozilla, and general questions on U.S. regulation of encryption technology.

Cryptographic functionality in Mozilla

Have all the issues with Mozilla and crypto now been resolved?

Almost. Now that the RSA patent is in the public domain, Mozilla crypto development can proceed with minimal restrictions. In the near future the Mozilla code base will include a complete open source cryptographic library, and Mozilla will include SSL support as a standard feature.

After the U.S. government relaxed U.S. export regulations in January 2000 to allow export of source code for open source software implementing encryption, the major remaining legal obstacle to Mozilla crypto development was the fact that RSA Security, Inc., held a U.S. patent on the RSA public key algorithm. In February 2000 iPlanet E-Commerce Solutions (a Sun-Netscape Alliance) released source code through mozilla.org for the Personal Security Manager and Network Security Services software; this source code included support for the SSL protocol, but due to the RSA patent and related legal issues it did not originally contain code for RSA or other cryptographic algorithms.

On September 6, 2000, RSA Security released the RSA patent into the public domain, two weeks before the patent was scheduled to expire (on September 20, 2000). Shortly thereafter the NSS developers began work on an open source implementation of the RSA algorithm; that code, together with code previously developed for other cryptographic algorithms, will be included in a new version 3.1 of the NSS open source cryptographic and PKI library.

This new RSA-capable version of NSS will then be included in a future version of the open source PSM software, which will provide SSL support for Mozilla. At that point both NSS and PSM will be completely buildable using the open source code available from the mozilla.org site, and NSS and PSM will be included in the Mozilla binary releases distributed by mozilla.org.

For more information on the RSA patent see the RSA Security press release announcing release of the patent into the public domain, and the RSA patent itself.

For information on new US encryption export regulations, see the U.S. Department of Commerce press release announcing the new regulations as well as the updated regulations (PDF) themselves. Export of source code for open source software is addressed in Part 740 (PDF), section 740.13(e), "Unrestricted encryption source code"; export of binaries is addressed in 740.17.

(You may also be interested in a more in-depth analysis of the new regulations, with an emphasis on how they affect open source software.)

For more information on the SSL, S/MIME, PKI, and other crypto source code being developed as part of the Mozilla project, see the PKI project page and of course the source code itself. Also see the original Sun-Netscape Alliance press release on the release of PKI source code and the corresponding mozilla.org press release.

What functionality is implemented by the Mozilla crypto code released so far? When will Mozilla get full support for SSL and S/MIME?

The Mozilla crypto code will shortly include a full implementation of the RSA and other cryptographic algorithms; that implementation will form the basis of a complete open source SSL implementation for Mozilla. S/MIME support is also under development, but may not be available in Mozilla until after the 1.0 release.

Version 3.1 of the Network Security Services library will include a complete open source implementation of the cryptographic algorithms needed for Mozilla SSL support, including the RSA public key algorithm (now in the public domain). NSS 3.1 will be available in beta form in September 2000, with the final release to follow in October 2000. NSS 3.1 will be used in the 1.3 release of PSM, which will provide a complete open source implementation of SSL for Mozilla. PSM 1.3 will also provide support for Mozilla users to obtain personal digital certificates and perform other PKI-related functions.

Note that due to various implementation issues, PSM support for Mozilla on the Macintosh is lagging somewhat behind PSM support on Windows, Linux, and other platforms. Also note that the NSS developers are creating code for support of S/MIME secure messages; however full S/MIME support within Mozilla will require further development, and may not be available until after the Mozilla 1.0 release.

Finally, note that NSS (and thus PSM) can also be built using a licensed copy of the RSA BSAFE Crypto-C library (versions 4.1 or 5.0). iPlanet E-Commerce Solutions has released Netscape-branded binary versions of Personal Security Manager that incorporate the RSA BSAFE Library; the Netscape PSM software can be installed and used with binary Mozilla versions.

For the very latest information about PSM, NSS, and other crypto-related Mozilla developments, see the mozilla.dev.tech.crypto newsgroup or the corresponding dev-tech-crypto mailing list. For more information on NSS 3.1 see the NSS 3.1 plan and the NSS 3.1 build instructions; for more information on PSM 1.3 see the PSM 1.3 task list posted by David Drinan.

For more information on the Netscape PSM binaries see the Netscape Personal Security Manager for Mozilla page.

What is the open source license used for the Mozilla crypto code?

The released source code is dual-licensed under the MPL and the GPL.

The Mozilla SSL, S/MIME, and PKI source code is licensed under the Mozilla Public License (version 1.1), with the GNU General Public License (version 2.0 or later) available as an alternate license. You may choose to use the code either under the terms of the MPL or under the terms of the GPL.

This form of licensing was chosen to allow the released Personal Security Manager and Network Security Services source code to be used in as many contexts as possible; for example, the PSM and NSS code can be used in Mozilla under MPL terms, and can also be used in GNU and other projects under GPL terms. If you create and distribute modifications to the original PSM and NSS code, we ask that you in turn make such modifications available under both the MPL and GPL. (Note that mozilla.org will not accept contributed modifications into future PSM/NSS source releases unless they are so licensed.)

For more information see the Mozilla Public License and the GNU General Public License. Specific questions about licensing of the PSM and NSS source code should be directed to the netscape.public.mozilla.license newsgroup or the associated mozilla-license mailing list.

Will mozilla.org accept new contributions of crypto code?

Yes, as long as patent or other legal issues do not prevent such code from being used by the general community of Mozilla developers. New contributions of crypto code should also be reviewed and approved by the appropriate Mozilla module owners, just as with any other Mozilla contributions.

For more information about patents related to cryptographic algorithms and implementation techniques, see the questions relating to patents on cryptography in RSA Laboratories' cryptography FAQ. See the Mozilla open source PKI projects pages for the names and email addresses of the Mozilla module owners for crypto-related code.

What about Mozilla support for PGP and other protocols besides SSL and S/MIME? Will we be able to use GNU Privacy Guard or other PGP versions with Mozilla?

Support for PGP and other security-related protocols and formats can potentially be added to Mozilla in the same manner as SSL and S/MIME; if anyone is interested in working on such support within the Mozilla project then they are welcome to do so. We know of at least two efforts which may produce PGP support for Mozilla.

As noted above, the PSM code implements SSL and (in the future) S/MIME support for Mozilla by taking advantage of generic high-level Mozilla public APIs used to add new protocols and message formats. These same APIs can be used to add support to Mozilla for other security schemes, including potentially PGP. If anyone is interested on working such support within the Mozilla project then they are welcome to do so. However note that, as with SSL and S/MIME, mozilla.org will not host code implementing patented algorithms that are not generally usable by all Mozilla developers (including Mozilla developers creating products for commercial sale and distribution).

Also note that Mozilla support for PGP and other security schemes may also be made available by commercial security vendors or by independent developers, using the various public APIs already present in Mozilla. Based on statements made in various Internet forums it appears that the developers of GNU Privacy Guard may create a plugin module to support invocation of GnuPG functionality from Mozilla; Network Associates may also create a commercial PGP plugin for Mozilla. You should contact those vendors or developers directly for more information concerning their plans.

See the Open Directory references for general PGP information, including contact information for companies and independent developers producing PGP implementations.

Is information available describing the format of the PSM key and certificate database, so that other software can reuse existing user keys and certificates managed by PSM?

Yes, documentation of the database format is available; however we cannot guarantee that the format of the database will remain unchanged in the future.

The initial release of SSL, S/MIME, and general PKI source code from iPlanet E-Commerce Solutions includes some documentation on the format of the key and certificate database. As with Mozilla documentation in general, mozilla.org will be glad to host any other documentation contributed to describe database formats, APIs, and other technical aspects of the released SSL, S/MIME, and PKI source code.

However, as with APIs internal to Mozilla modules, mozilla.org cannot guarantee that the format of the key and certificate database will remain unchanged over time; in particular, changes may be introduced at some point that break compatibility with existing applications. Also, changing the database directly from an application risks causing database corruption and subsequent problems in PSM and applications like Mozilla using PSM. For these reasons we strongly recommend that Mozilla developers and others access the key and certificate database only through public APIs provided by the NSS library.

For more information see the documentation for the cert7.db certificate database. Also see the documents "Into the Black Box: A Case Study in Obtaining Visibility into Commercial Software", "Netscape Certificate Database Information", and "Netscape Communicator Key Database Format", the results of independent attempts to describe the format of the Netscape Communicator 4.x key and certificate database (with which the PSM key and certificate database format is compatible).

Information for Mozilla contributors

I want to mirror the Mozilla FTP site. Do I need to do anything with regard to U.S. encryption export controls?

No, you do not. As long as you are simply mirroring the Mozilla site as is, you do not need to provide any notification to the Bureau of Export Administration or NSA. If you are outside the U.S. you do not need to provide such notification in any case, but you may need to take other actions to comply with laws and regulations in your own country concerning encryption technologies.

As a mirror of the Mozilla FTP site you will automatically be distributing open source encryption code as well. If you are a U.S. resident and/or your mirror site is in the U.S. then you are required to comply with applicable U.S. regulations governing the export of encryption software. Your particular obligations depend on your exact circumstances, and we cannot provide legal advice to you.

However, in an advisory opinion issued in reference to the Bernstein case, the Bureau of Export Administration (BXA) has stated the following: "Concerning the posting onto a mirror or archive site of already-posted source code, notification is required only for the initial posting." BXA and NSA have already been notified of the posting of encryption-related source code on the Mozilla site, and in light of this opinion we have therefore decided not to ask mirror sites to provide notification themselves.

Note that in any case the notification procedures outlined in the Export Administration Regulations apply only to U.S. residents and sites located in the U.S. If you are not a U.S. citizen or resident and your mirror site is located outside the U.S. then you are not subject to U.S. encryption export regulations; however you may be subject to other regulations related to encryption, and are responsible for complying with any such regulations applying in your jurisdiction.

For information on notification requirements related to the export of open source encryption source code, see the Export Administration Regulations, in particular Part 740, sections 740.13(e), "Unrestricted encryption source code", and 740.17(g), "Reporting requirements". For the statement by the Bureau of Export Administration on notification requirements for mirror sites, see the section "Notification Requirements" in the Bernstein advisory opinion contained in the letter dated February 17, 2000, from James Lewis of BXA to Cindy Cohn, counsel for Daniel Bernstein.

Further information on U.S. export controls on encryption software

What are the relevant U.S. government laws and regulations governing export from the U.S. of encryption software?

The Export Administration Regulations, the Export Administration Act of 1979, and related U.S. presidential executive orders address export of encryption software from the U.S.

The main U.S. government regulations governing the export from the U.S. of cryptographic software are the Export Administration Regulations (EAR), also known as 15 CFR chapter VII subchapter C, or 15 CFR Parts 730-774. ("CFR" stands for "Code of Federal Regulations.") The Export Administration Regulations were created by the Bureau of Export Administration (BXA) and were designed primarily to implement the requirements of the Export Administration Act of 1979 (as amended), also known as 50 USC appendices 2401-2420. ("USC" stands for "United States Code.") The EAA was passed as temporary legislation; however the President of the United States has periodically issued orders to continue the EAA and EAR, exercising authority under the International Emergency Economic Powers Act, also known as 50 USC 1701-1706.

For more information see 15 CFR Part 730, section 730.2 (concerning statutory authority for the EAR), and the document "Principal Statutory Authority for the Export Administration Regulations", which contains copies of the Export Administration Act of 1979 (as amended), the International Emergency Economic Powers Act (as amended), and related legislation and executive orders.

I thought export of encryption software from the U.S. was governed by the International Traffic in Arms Regulations. What happened to the ITAR?

The ITAR still exist, but are no longer used in the context of export control of encryption software; for this purpose they have been replaced by the EAR.

Authority for non-military encryption export was transferred from the U.S. State Department to the U.S. Department of Commerce by Presidential Executive Order 13026 on November 15, 1996, for regulation under the Export Administration Regulations (EAR), along with all other export-controlled commercial products. At that time encryption hardware, software, and technology was transferred from the U.S. Munitions List to the Commerce Control List (CCL) of the EAR.

For more information see the document "Principal Statutory Authority for the Export Administration Regulations", which contains a copy of Executive Order 13026.

Haven't U.S. export controls on encryption software already been ruled unconstitutional?

Yes in a specific case, but the decision may yet be overruled. Also, the case itself may be declared moot in light of the new U.S. encryption export regulations.

For several years Professor Daniel Bernstein (currently at the University of Illinois at Chicago) has pursued a lawsuit against the U.S. government essentially claiming that U.S. export control regulations on encryption software and related conduct with regard to cryptography (e.g., "technical assistance") were unconstitutional. (Bernstein's suit was originally directed at the ITAR and related regulations, since at the time the suit was filed the current Export Administration Regulations were not yet in effect with respect to encryption software.) Bernstein claimed that the U.S. export regulations were in essence a licensing scheme designed to impede or prohibit certain types of speech (e.g., publishing cryptographic source code in electronic form), and were therefore unconstitutional under the First Amendment to the U.S. constitution. The U.S. government claimed in return that cryptographic software was regulated based solely on its ability to be used to secure communications and data, and that the national security interest in so regulating it overrode any First Amendment protections; as the export regulations put it, "encryption software is controlled because of its functional capacity, and not because of any informational value of such software". The government also claimed that publication of cryptographic software in electronic form made such functional use easier than publication in printed form, and that that was sufficient to justify treating the two forms differently in the regulations.

On August 25, 1997, the U.S. District Court for the Northern District of California issued a final ruling (written by Judge Marilyn Hall Patel) that "the [U.S. government] encryption regulations are an unconstitutional prior restraint in violation of the First Amendment." The U.S. government appealed this decision to the U.S. 9th Circuit Court of Appeals, and on May 6, 1999, the court upheld the District Court's ruling in a 2-1 decision, with Judge Betty Fletcher writing for the majority that the ITAR and EAR export restrictions against encryption are an unconstitutional prior restraint of free expression, impermissible under the First Amendment to the U.S. Constitution.

However this ruling did not settle the issue of the constitutionality of U.S. export control regulations. The U.S. Department of Justice has sought to appeal the decision, first to all eleven members of the 9th Circuit Court of Appeals (referred to as the court en banc, or full court) and then possibly to the U.S. Supreme Court. Until the appeals process is completed the U.S. government will continue to enforce current U.S. export regulations.

In light of the new encryption export regulations it is also possible that the Bernstein case may be declared moot on the basis that Professor Bernstein is now free to do what he originally requested to do, i.e., publish his encryption source code online.

For more information see the archives on the Bernstein case maintained by the Electronic Frontier Foundation, particularly the 9th Circuit Court of Appeals ruling, the press release issued by the U.S. Bureau of Export Administration immediately afterward, and the U.S. Export Administration Regulations themselves, particularly 15 CFR Part 774, Supplement No. 1, Category 5, Part 2, entry 5D002 (note on "functional capacity") and 15 CFR Part 734, paragraphs 734.3(b)(2) and (b)(3) and accompanying note (printed form vs. electronic form). See also the request for an advisory opinion made to the Bureau of Export Administration by Bernstein's lawyers and the resulting advisory opinion issued by BXA in response to that request.

Where can I learn more about U.S. export controls on encryption software?

For more information on U.S. export control of encryption software and related topics, see the following online references:

• The ITAR, EAR and encryption export archive maintained by the Electronic Freedom Foundation (EFF).
• The cryptography policy page maintained by the Electronic Privacy Information Center (EPIC).
• The encryption page maintained by the Center for Democracy and Technology (CDT).

The following books may also be of interest if you want to know more about the history and politics of U.S. export control of encryption software:

• Privacy on the Line: The Politics of Wiretapping and Encryption, by Whitfield Diffie and Susan Landau. Provides historical context and technical background for the recent political battles around encryption and privacy issues.
• Technology and Privacy: The New Landscape, by Philip Agre and Marc Rotenberg (ed.). A set of ten essays on various aspects of privacy and technological developments affecting it.
• The Electronic Privacy Papers: Documents on the Battle for Privacy in the Age of Surveillance, by Bruce Schneier and David Banisar (ed.). A collection of public documents relating to U.S. encryption policy and related topics.
• Building in Big Brother: The Cryptographic Policy Debate, by Lance Hoffman (ed.). An earlier (circa 1995) collection of essays and public documents, with a concentration on the Clipper chip controversy and the Digital Telephony Act.
• Cryptography & Liberty 2000: An International Survey of Encryption Policy, by the Electronic Privacy Information Center. The latest in a series of annual surveys of government policies relating to encryption, covering over a hundred countries.
• The Limits of Trust: Cryptography, Governments, and Electronic Commerce, by Stewart Baker and Paul Hurst. An in-depth (but badly outdated) discussion of the legal framework for regulation of cryptography in various countries around the world, including the U.S.

See the EPIC bookstore for more recommendations of books discussing privacy in general and public policies related to privacy issues.