Microsoft Corporation
September 10, 1996
Updated: December 3, 1996
(November 15, 1996 Executive Order)
Note Please note that this information is provided for the convenience of Microsoft customers only. No warranty is made as to its accuracy, completeness, timeliness, or suitability for any particular purpose. If you are uncertain regarding the application of this information to your particular situation, or have any questions about whether your product requires an export license, please contact the Department of State, Office of Defense Trade Controls at (703) 875-6643 or fax (703) 875-6647, or consult with legal counsel.
Export Issues
November 15, 1996 Executive Order
U.S. Export Controls on CryptoAPI Components
We believe that key lengths must be lengthened substantially to provide our worldwide customers strong security and privacy. Microsoft is working actively with other companies in our industry to encourage the U.S. government to relax its restrictions on export controls. For more information, please see the Business Software Alliance's Web site (http://www.bsa.org/).
U.S. independent software vendors (ISVs) should be aware that under existing export law, applications that get their security from third-party providers or implement encryption on their own are export-controlled, and vendors must file Commodity Jurisdiction (CJ) requests with the State Department to obtain export approval. However, because the cryptography application programming interface (CryptoAPI) effectively removes cryptographic security from the application and compartmentalizes security services in the cryptographic service provider (CSP), we expect U.S. export authorities will waive the CJ requirement for CryptoAPI-enabled applications that do not otherwise implement secure functions, as soon as their regulations have been amended to allow them to do so. We are working with U.S. export authorities to identify any areas of concern or types of CryptoAPI-enabled applications that still might require CJ or other licensing review. We will publicize this policy when it becomes available. Until then, application writers are advised to consult legal counsel and the State Department, Office of Defense Trade Controls, to determine the appropriate export clearance procedure for their applications.
The first question is, "Do you plan to export your CSP?" If not, complete the Export Compliance Certificate in the Cryptographic Service Provider Developer's Kit (CSPDK) and certify that you will distribute your CSP only in the United States or Canada. Return the certificate to Microsoft. When you are ready, make an appointment for Microsoft to sign your CSP.
If you do plan to export your CSP, complete the Export Compliance Certificate in the CSPDK and certify that you intend to export your CSP from the United States or Canada, and return the certificate to Microsoft. Then do the same thing you do for any product subject to U.S. export controls: obtain export approval from a U.S. export licensing authority. Provide evidence of your export approval to Microsoft (which Microsoft will independently confirm), and when you are ready, make an appointment for Microsoft to sign your CSP.
The first issue is the process of obtaining the CSPDK from Microsoft. Because both the CSPDK and the signature of CSP are export-controlled (one as a munition, the other as a defense service), Microsoft will need export licenses, both to ship a CSPDK outside the United States or Canada and to sign a CSP developed outside the United States or Canada.
Microsoft will make the CSPDK available to foreign developers and will sign CSPs from foreign developers to the best of its ability under export law. Microsoft will seek to obtain these export licenses from the government so long as there is a likelihood of approval. At present, U.S. export law is very restrictive in this sense, and we do not anticipate many approvals of foreign CSPs except as follows:
ISVs. U.S. ISVs should be aware that under existing export law, applications that get their security from third-party providers or implement encryption on their own are export-controlled, and vendors must file Commodity Jurisdiction (CJ) requests with the State Department to obtain export approval. However, because CryptoAPI effectively removes cryptographic security from the application and compartmentalizes security services in the CSP, we expect U.S. export authorities will waive the CJ requirement for CryptoAPI-enabled applications that do not otherwise implement secure functions, as soon as their regulations have been amended to allow them to do so. We are working with U.S. export authorities to identify any areas of concern or types of CryptoAPI-enabled applications that still might require CJ or other licensing review. We will publicize this policy when it becomes available. Until then, application writers are advised to consult legal counsel and the State Department, Office of Defense Trade Controls, to determine the appropriate export clearance procedure for their applications.
CSP Vendors. Under CryptoAPI, CSP vendors and their products are subject to the same U.S. export controls they face today. Vendors should maintain appropriate export control on CSPs not eligible for export and obtain export approvals for those that are eligible.
As promised in the Clinton Administration's October 1, 1996 announcement, this executive order transfers jurisdiction over commercial encryption exports from the State Department to the Commerce Department as soon as the Commerce Department completes new regulations implementing the order (estimated to be December 1996).
While at first glance this executive order appears to end the munitions treatment of commercial encryption products, the transfer by itself does little to liberalize export controls because many Commerce policies will be inapplicable to encryption products.
Although the Clinton Administration's recent announcements regarding key recovery are a step in the right direction, they do not address our customers' demand for longer key lengths (128-bit) for Internet applications, especially those related to electronic commerce. More progress is needed in liberalizing U.S. export laws so that U.S. companies can compete on a level playing field with foreign vendors and provide our worldwide customers strong security and privacy.
Please see Microsoft Policy on Export Controls on Encryption for more detail about the Microsoft perspective on software and export controls.
No, 128-bit encryption is still restricted by the U.S. government for virtually all foreign users, with the possible exception of certain government or military customers on a case-by-case basis. Microsoft is still actively lobbying the U.S. government to change the regulations enabling export of 128-bit encryption for Internet financial applications.
Based on the new policy, the Administration provides temporary export licenses for 56-bit products if companies "demonstrate" a commitment to key recovery systems. But the proposal provides little detail about what this means in practice. Any definition of key recovery must be commercially driven or it is bound to fail. Unfortunately, early indications are that the U.S. government is still thinking in terms of a "Clipper-like" mandatory key escrow.
Microsoft already sells several products that allow systems administrators to recover keys. Market-driven features in the Microsoft® Exchange Server enable users to recover lost data or replace lost or stolen keys, and Microsoft Windows® operating system is built so that any vendor can plug in a variety of security solutions—including key recovery technology (CryptoAPI). We trust and expect that these efforts will be viewed as sufficient to demonstrate support for key recovery for purposes of temporary export licenses.
No. We still need 128-bit relief for Internet financial applications. This is not a future need—customers today reject the Data Encryption Standard (DES) and demand 128-bit protection for financial data. If we cannot supply these products, foreign vendors will (and they already are). This places U.S. companies at a competitive disadvantage. The executive order requires that exported software have a lower level of security protection than is available within the United States. Microsoft believes that key lengths must be lengthened substantially in order to provide our worldwide customers strong security and privacy. The Administration's proposal does not directly address this issue.
Government key escrow refers to the U.S. government holding or having access to a user's private encryption key (such as the Clipper Chip). Although key escrow systems are exportable with longer keys (Clipper has an 80-bit key), such systems are designed with a mandatory key escrow feature (that is, it cannot be turned off and the government has some way to verify this as a condition of export approval).
Key escrow encryption is not a market-driven solution and it raises serious privacy concerns for many customers. It is also new, undeveloped, untested, and uncosted, and it will take a long time to be worked out. Additionally, customers have expressed hesitation about mandatory key escrow, especially if they have to give the keys to the government or a government-selected third party. Therefore, we are not actively adding support for key escrow in our products and technologies.
Strong non-key escrow encryption is already available from retail outlets, foreign companies, and from Internet sites. Thus the U.S. government already has—and will continue to have—difficulties accessing plain text regardless of U.S. export restrictions.
CryptoAPI is not a key escrow system. Rather, it is a programming interface that provides our customers with two main benefits:
No. U.S. export law limits the export outside the U.S. or Canada of products that host strong encryption or an open cryptographic API. However, U.S. export law does not regulate the type of product or strength of encryption vendors can deploy within the U.S. or Canada. CryptoAPI enables vendors of encryption technology to develop strong encryption CSPs for use in the U.S. and Canada, as well as CSPs that can obtain export approval for worldwide distribution. Conversely, CryptoAPI enables software developers to create and distribute worldwide one application that will be able to use the maximum-strength encryption enabled by U.S. law, based on the type of CSP the user has available on their computer.
In order for a CSP to work with CryptoAPI and be recognized by the operating system, it must be digitally signed by Microsoft. The primary purpose of the digital signature is for the protection of the system and its users: by signing the CSP, the integrity of the CSP can be guaranteed to the operating system. The operating system validates this signature periodically to ensure that the CSP has not been tampered with.
Additionally, the signature requirement also separates applicable U.S. export controls on the CSP from the host operating system and applications, thereby allowing broader distribution of encryption-enabled products than would be possible under other circumstances. The signature requirement demonstrates that Microsoft and the CSP vendor have taken steps to comply with U.S. export laws if there is an intent to export the CSP. Because unrestricted access to CryptoAPI would make the host operating system ineligible for export, the signature requirement limits access to CryptoAPI to vendors who agree to implement CSPs in conformity with U.S. export law.
Market-driven data recovery refers to a product feature that allows users to maintain a spare private encryption key in a safe place. Generally, a data recovery system escrows a copy of the session key with the message or file and the user (or perhaps his employer) controls the decision whether to utilize this feature. With key escrow the U.S. government holds or has access to a user's private encryption key.
It is not yet clear whether such systems are exportable. In the October 1 announcement, the U.S. government referred to "key recovery" without defining it; in all likelihood, however, they still have in mind government key escrow, and not market-driven data recovery.
Customers have told us that market-driven key recovery is an important feature. Microsoft already sells e-mail products that allow systems administrators to recover keys. We are adding data recovery features to the Microsoft Windows NT® operating system. And Windows is built so that any vendor can plug in a variety of security solutions—including key-recovery technology (CryptoAPI).
We do. U.S. customers are demanding stronger cryptography and we are satisfying that demand with a 64-bit version of Exchange and 128-bit version of Microsoft Internet Explorer and Internet Information Server. But even our U.S. customers need to operate globally, and foreign customers are not satisfied with "crypto lite." Therefore, we need export relief so that we can sell a single product worldwide.
According to our information, France is the only other country that controls imports or the use of encryption.
No. If foreign companies can provide software with strong encryption and U.S. companies cannot, American software will no longer compete. Software from foreign companies with strong encryption will fill in the void.
According to our interpretation of the U.S. government announcement, no U.S. companies are in a position to offer this kind of technology—either directly or indirectly. The restrictions that apply to Microsoft regarding what we can legally do or say in support of these add-ons (relatively little without violating U.S. export law) also apply to our competitors. If the U.S. government were to change its policy and permit any U.S. company to export 128-bit cryptography to some preferred group of customers, they would permit all U.S. companies (with similar implementations) to take advantage of this new policy.
Yes. The CryptoAPI interface in Windows NT 4.0 can be exported without restriction to all destinations except countries and entities under U.S. embargo or restriction (for example, Cuba, Libya, North Korea, Iran, Iraq, and Syria).
The CSP Developer's Kit (CSPDK) is subject to State Department licensing, and as such its export from the United States or Canada is limited. In all instances, the CSPDK requires a State Department license to be exported from the United States or Canada, which will be issued to Microsoft only on a case-by-case basis.
Yes. The CryptoAPI Application Programmer's Guide is available from the Microsoft Site Builder Network Web site (http://www.microsoft.com/workshop/prog/security/capi/cryptapi.htm). The guide, the sample code, and the Microsoft Win32® Software Development Kit (SDK), which contains the header files (WINCRYPT.H), are eligible for export to nearly all destinations (except the embargoed countries).