) for more information.
February 21, 1996
What advantages does CryptoAPI have?
Which operating systems support CryptoAPI?
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?
Microsoft's Role Regarding CSPs
Why does CryptoAPI require that Microsoft sign Cryptographic Service Providers (CSPs)?
What are Microsoft's criteria for signing CSPs?
Where will Microsoft perform the CSP signing operation?
Does Microsoft derive any rights to my CSP or share any responsibilities once it is signed?
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?
The Microsoft® Cryptographic application programming interface (CryptoAPI) has two main benefits:
Applications don't need their own cryptographic code; developers don't need to learn the details of cryptographic functions.An important benefit of isolating applications from cryptographic services is that we expect that applications that call CryptoAPI should not have export restrictions. We will have more information about this in the near future.
CryptoAPI will open up markets for CSP developers. 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 allows vendors to develop strong encryption CSPs for Win32® systems and efficiently deliver them to customers to the maximum extent allowed by existing law. CryptoAPI will be most useful to vendors selling strong security products in the U.S. or Canada, and also to vendors selling into specific global markets (that is, banks and financial institutions, or U.S. multinationals) that enjoy somewhat broader access to strong encryption security under U.S. export law. Microsoft is hopeful that CryptoAPI will facilitate the export of strong encryption to other overseas vertical markets such as foreign governments, and non-U.S. multinationals such as pharmaceutical, petroleum, and aerospace companies.
Back to list of questionsCryptoAPI will be supported in Windows NT® 4.0. CryptoAPI has appeared in the Windows NT 4.0 beta; header files will be available in the accompanying Win32® Software Development Kit (SDK).
The best way to receive copies of this beta and the SDK is to sign up for the Microsoft Developer Network (MSDN) Level 2. To subscribe, call (800) 759-5474, or check out the MSDN Web page (http://www.microsoft.com/msdn) for more information.
CryptoAPI 1.0 will be supported in Windows® 95 through the release of Microsoft Internet Explorer 3.0. CryptoAPI 1.0 will then be shipped as part of an upcoming update to Windows.
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. 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 both make the CSPDK available to foreign developers, and 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:
Back to list of questionsISVs. 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.
The primary purpose of the digital signature is for the protection of the system and its users. Microsoft signs all CSPs to guarantee the integrity of the CSP to the operating system. Every CSP must be digitally signed by Microsoft in order to be recognized by the operating system. The operating system validates this signature periodically to ensure that the CSP has not been tampered with.
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.
Microsoft will sign CSPs subject only to the export limitations mentioned above. We will sign CSPs from competitors.
We will sign CSPs at our facilities in Redmond, Washington, USA.
Microsoft obtains no rights to a vendor's CSP by virtue of signing them. Neither do we assume any responsibilities for the CSPs we sign. CSP vendors are wholly responsible for the distribution, disposition, and possible end-use of their CSP, including any possible export or diversion of the CSP outside North America, irrespective of Microsoft digitally signing the CSP. The CSP vendor is solely responsible for meeting the terms of all U.S. export or other national controls over their CSP modules.
Back to list of questionsBack to list of questionsYes. 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 CryptAPI 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).