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 include
information on the new U.S. encryption export regulations published on
January 14, 2000, and the release on February 11, 2000, of source code
for SSL, S/MIME, and general PKI functionality for use in the Mozilla
project.
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.
Have all the issues with Mozilla and crypto now
been resolved?
No, but the situation is significantly better than it was when
Mozilla source code was first released.
At the time Mozilla source code was originally released in 1998
U.S. export control regulations essentially made it impossible for
Netscape to release encryption-related source code or for mozilla.org
to host such code on its site. On January 14, 2000, the
U.S. government published new export regulations that significantly
loosen controls on export of encryption products from the U.S., and in
particular allow export of source code for open source software
implementing encryption, including offering such source code for
anonymous downloading over the Internet.
On February 14, 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 code was
originally developed to provide SSL, S/MIME, and general Public Key
Infrastructure (PKI) functionality for Netscape Communicator and the
Netscape server products, and is currently being developed by iPlanet
E-Commerce Solutions for use with iPlanet e-commerce products and
future versions of the Netscape client.
However there are still some remaining issues with Mozilla and
crypto. First, the changes to the U.S. export regulations do not
completely eliminate controls on export of encryption software and
technology; there are some remaining restrictions, particularly with
regard to export of binaries, and some ambiguities in the regulations
that may affect Mozilla development activities.
Even more important, the release of source code from iPlanet
E-Commerce Solutions does not include all the code needed to
produce a complete SSL- or S/MIME-capable Mozilla product starting
with only source code. See the next question for more information.
Finally, the S/MIME source code that has been released is not yet
integrated into Mozilla; this will require further development.
On a more positive note, Mozilla's current architecture allows
security and crypto support to be more easily added than in the past
(i.e., in the "Mozilla Classic" code base). Mozilla implements
high-level generic APIs by which support for SSL, S/MIME, and other
security functions can be added by independent "add-on" software;
these APIs are not specific to cryptography or security, and can be
used to add other protocol-specific functionality, e.g.,
special-purpose web proxy functionality or custom handling of email
message attachments.
For information on new US encryption export regulations, see the
U.S. Department of Commerce
press
release
announcing the new regulations, the
actual
revisions
to the regulations, and the
updated regulations
themselves.
Export of source code for open source software is addressed in
Part 740,
section 740.13(e), "Unrestricted encryption source code"; export of
binaries is addressed in 740.17.
What's missing from the Mozilla crypto code
released so far? How will Mozilla get full support for SSL and S/MIME,
including RSA support?
The SSL and S/MIME code released through mozilla.org thus far is
missing the actual encryption code itself, as well as some other code
not yet released or releasable. However in the meantime iPlanet
E-Commerce Solutions will be releasing branded binary versions of
Personal Security Manager that can be installed and used with binary
Mozilla versions.
As noted previously, the PKI source code released thus far by
iPlanet E-Commerce does not include all the source code necessary to
build complete binary versions of Personal Security Manager and
Network Security Services from source. The source code not released
falls into the following general categories:
Proprietary source code licensed from third-parties, most notably
RSA Security, Inc. This code implements the underlying encryption
algorithms (RSA, RC4, DES, etc.) as well as related operations such as
"bignum" arithmetic; almost all of this code is in the internal
cryptographic module invoked from NSS using the PKCS#11 API. This
category of code will not be released in the future, unless for some
reason RSA Security someday decides to make it available under an open
source license.
Source code which contains some elements which might be considered
proprietary information of RSA Security, Inc., or other third
parties. This code was created by Netscape developers or contractors,
but contains information which may be considered proprietary by RSA
Security or other third parties, such as names and argument types of
proprietary functions in third-party libraries. This category of code
will be released in the future, after revising the code to eliminate
references to the third-party proprietary information.
Other source code for which iPlanet E-Commerce Solutions has not
yet secured permissions to release. This code is known to have been
created by third parties, but the licensing is uncertain or the
parties in question have not yet given permission to release the
code. Most if not all code in this category should be released in the
future, after clarifying licencing or securing the necessary
permissions.
Even though iPlanet E-Commerce Solutions cannot release all the source
code for PSM and NSS, it will be releasing Netscape-branded binary
versions of PSM which include the unreleased code in binary
form. These Netscape PSM binaries will be available for download from
the iPlanet web site, and can be installed and used with Mozilla
binaries built from the Mozilla source tree; the Netscape PSM binaries
will provide Mozilla builds with the ability to do SSL connections to
SSL-capable servers, generate private/public key pairs, get digital
certificates, and perform other PKI-related functions.
Providing Mozilla with the ability to send and receive S/MIME
signed and/or encrypted messages will require additional integration
between Mozilla and the contributed S/MIME code; note that mozilla.org
cannot commit to a date or release for when this integration will
be completed.
More information about the Netscape Personal Security Manager
binaries will be available in the future on the iPlanet
security
product information page; when they become available Netscape PSM
binaries will be downloadable from the iPlanet
download site.
What is the open source license used for the
released SSL, S/MIME, and PKI source code?
The released source code is dual-licensed under the MPL and
the GPL.
The SSL, S/MIME, and PKI source code released by iPlanet E-Commerce
Solutions 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.)
Discussions 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 contributions of code
to replace the encryption code not being released?
Not at present, since RSA patent issues currently prevent such code
from being used by Mozilla developers in the U.S.
As noted previously, iPlanet E-Commerce Solutions will not be
releasing the core encryption code called by the SSL, S/MIME, and
general PKI code, since such code contains proprietary code licensed
from a third party (RSA Security, Inc.) and implementing an encryption
algorithm (the RSA public key algorithm) which is subject to patent
restrictions in the U.S. It is possible to write new source code
reimplementing the RSA public key algorithm and related functionality
found in the code not released; however Mozilla developers in the
U.S. cannot generally make use of such code without infringing on the
RSA patent. (For example, they cannot use such code in a commercial
context.)
Therefore mozilla.org has decided that at this time we will not
accept any source code into the official Mozilla tree that implements
the RSA algorithm or related algorithms subject to patent restrictions
that prevent their general use by Mozilla developers. We will revisit
this decision at a later time. (Note that the RSA algorithm patent
will expire on September 20, 2000.)
Also note that security protocols exist which do not depend on
algorithms encumbered by patent, trade secret, or other restrictions
related to intellectual property claims. For example, the Transport
Layer Security protocol (based on the SSL protocol) includes TLS
ciphersuites based solely on algorithms in the public domain;
similarly the S/MIME version 3 protocol mandates support for key
exchange, digital signature, and other mechanisms based on algorithms
in the public domain. If you wish to assist with development of
unencumbered TLS or S/MIMEv3 functionality for Mozilla then we
encourage you to contact the module owners for SSL and S/MIME.
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.
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.
Will mozilla.org release information on 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.
I want to mirror the Mozilla FTP site. Do
I need to do anything with regard to U.S. encryption export
controls?
Yes, you may need to provide notification to the Bureau of Export
Administration and NSA. If you are outside the U.S. you do not need to
provide such notification, but 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 we can tell you of the particular steps we have taken
to comply with the new export regulations, and we recommend that you
consider taking similar action yourselves.
In particular, we have provided notification to the Bureau of
Export Administration and the National Security Agency of our posting
of open source encryption source code in accordance with section
740.13(e) of the Export Administration Regulations, and as part of
that notification have supplied BXA and NSA with the URL(s) at which
mozilla.org will be hosting such source code.
You can provide such notification yourself by sending an email
message to BXA at the address
crypt@bxa.doc.gov
and by sending a letter to NSA at the postal address
Attn: ENC Encryption Request Coordinator
9800 Savage Road
Suite 6131
Ft. Meade, MD 20755-6000
provide the URL(s) at which you will be mirroring the code.
We are also placing notices on our site where appropriate regarding
applicable export restrictions. This is the notice we plan to place
with our source code and on the mirror page, and which you may use on
your own site:
This source code is subject to the U.S. Export Administration
Regulations and other U.S. law, and may not be exported or re-exported
to certain countries (currently Afghanistan (Taliban-controlled
areas), Cuba, Iran, Iraq, Libya, North Korea, Serbia (except Kosovo),
Sudan and Syria) or to persons or entities prohibited from receiving
U.S. exports (including Denied Parties, entities on the Bureau of
Export Administration Entity List, and Specially Designated
Nationals).
Note that the notification procedures described above 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".
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.
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.
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.
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.
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.
