 | ||
|
| ||
| ||
|
| ||
Microsoft Corporation
Updated: December 3, 1996
Export Issues
What is Microsoft's position on export controls?
What export issues do ISVs developing Win32 applications that call CryptoAPI need to think about?
What export issues do domestic (U.S. and Canada) developers writing CSPs need to think about?
What export issues do foreign developers writing CSPs need to think about?
Are the obligations of developers under U.S. export laws any different under CryptoAPI than without it?
November 15, 1996 Executive Order
What exactly does the November 15 executive order implement? What is Microsoft's position regarding the announcement?
Does the November 15 announcement enable Microsoft to export 128-bit SSL and PCT for secure communications and transactions on the Internet?
Does the announcement permit companies to begin exporting products with 56-bit encryption?
Does Microsoft sell any key recovery products that will allow it to export 56-bit encryption?
Will 56-bit encryption meet the encryption needs of the worldwide market?
What is key escrow?
What is Microsoft's position on supporting key escrow?
Shouldn't the U.S. Government be able to access information that could prevent terrorist acts and crime?
Have you already done key escrow encryption in the form of Microsoft's CryptoAPI?
Does CryptoAPI allow plug-and-play cryptography without any export restrictions?
What is key recovery? How does it relate to key escrow?
What is Microsoft's position on supporting key recovery?
Does Microsoft sell a domestic and foreign version of software programs with different levels of encryption?
Other countries also control the export of encrypted products; why shouldn't the United States?
If we control general-purpose applications where encryption is built-in and easy to use, rather than stand-alone products, don't we effectively limit the widespread use of encryption?
Another software firm based in the United States told me they can offer 128-bit solutions written outside of the U.S. Why can't Microsoft?
U.S. Export Controls on CryptoAPI Components
Which elements of CryptoAPI are subject to State Department (ITAR) licensing?
Which elements of CryptoAPI are subject to Commerce Department (Commerce) licensing?
Is CryptoAPI exportable?
Is the CSP Developer's Kit exportable?
Is the CryptoAPI Application Programmer's Guide and sample code exportable?
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, (703) 875-6643 or FAX (703) 875-6647, or consult with legal counsel.
We believe that key lengths must be lengthened substantially to provide our worldwide customers strong security and privacy. We are 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 home page, 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 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.
The first question is, "Do you plan to export your CSP?"
If not, complete the Export Compliance Certificate in the CSP Developer's Kit and certify that you will distribute your CSP only in the U.S. 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 CSP Developer's Kit and certify that you intend to export your CSP from the U.S. 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 CSP Developer's Kit (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 U.S. or Canada and to sign a CSP developed outside the U.S. 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 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).
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.
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 "Clipper-like" mandatory key escrow.
Microsoft already sells several products that allow systems administrators to recover keys. Market-driven features in Exchange Server enable users to recover lost data or replace lost or stolen keys, and Windows® 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 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. It still requires that software being exported have a different (lower) level of security protection than is available within the United States. Microsoft believes that key lengths must be lengthened substantially 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's 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 off the Internet. Thus the U.S. government is already having--and will continue to have--a harder time in the future 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:
First, system-level access to common cryptographic functions (such as key generation, key exchange, data encryption and decryptions, hashing and digital signatures). This enables ISVs to access cryptographic services, without having to develop their own cryptography or apply for export licenses (the mere fact that an application calls CryptoAPI does not subject it to export restrictions).
Second, renewable, replaceable security. CryptoAPI isolates the application from the Cryptographic Service Providers (CSPs), that is, cryptography modules, allowing use of different CSPs as required. For example, as cryptographic requirements increase, or the security of cryptographic algorithms change, different CSPs can be used without changing the application.
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 one application worldwide 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 Windows NT®. 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 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 can be exported without restriction to all destinations except countries and entities under U.S. embargo or restriction (e.g., 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 U.S. or Canada is limited. In all instances, the CSPDK requires a State Department license to be exported from the U.S. 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 Developer Network and from the Microsoft CryptoAPI home page. The guide, the sample code, and the Win32 SDK, which contains the header files (WINCRYPT.H), are eligible for export to nearly all destinations (except the embargoed countries).
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top