Note: for index of full report see: http://jya.com/nrcindex.htm

---------



                              K


      Cryptographic Applications Programming Interfaces


   Modern software systems are built using various techniques
that provide flexibility and reliability. One of the most
important techniques centers on the use of an applications
programming interface.

   An applications programming interface (API) is a
well-defined boundary between two system components that
isolates a specific process or set of services. For example,
it is quite common now for an application to interact with an
electronic mail (e-mail) server through an e-mail API, such as
MAPI (Microsoft), VIM (Lotus), or AOCE (Apple), to name a few.
In such cases, the API defines a set of services that allow an
application to retrieve or submit mail messages from or to the
mail server. APIs can be implemented by using hardware,
software or some combination. Furthermore, software APIs can
be implemented by using dynamically linked libraries,
statically linked libraries, remote procedure calls (RPCs) or
any combination.

   APIs have evolved as the result of both technical and
business pressures. Technically, software developers have
moved increasingly to "open," client-server systems. An open
system is one in which interoperable products from different
vendors are used to provide the functionality required by the
users. Such systems depend heavily on commercial standards and
APIs are often used to support those standards. For example,
email exchange using the X.400 standard is now supported by
the CMC API. An API allows multiple vendors to develop
interoperable products, even though individual product
versions are continually changing.

   Although APIs are used to support open standards, a large
number of proprietary APIs are also used by vendors to
safeguard their technical investments. Even within these
closed environments, APIs provide a major technical and
business benefit for those vendors licensed to develop
products using that API. For example, Novell was one of the
first network operating system vendors to make extensive use
of an API to support a wide range of add-on products. Under
its approach, a NetWare Loadable Module (NLM) can be developed
by a third party developer and incorporated into an
operational system by the user. The use of a proprietary API
allows vendors to maintain the quality of third party
products, to provide a basis for the development of niche
products, and to maintain a competitive advantage. In Novell's
case, the development of NLMs for major database products has
boosted its sales in that competitive server market.

   Perhaps the most common API today is Microsoft's object
linking and embedding (OLE) software technology, which
provides general-purpose sockets for modules that can
undertake many different functions. For example, an OLE socket
can provide the user with the capability to insert a module
for file encryption or for file compression. Thus, although it
might be possible to use government regulations to prevent the
widespread use of sockets for encryption, it would be
difficult to dampen the spread of a general-purpose socket
that has many uses. OLE interfaces could plausibly support
some level of encryption capability; however, since OLE
interfaces are not specifically designed for security, they
may have weaknesses that render them unsuitable for
security-specific applications.

   A cryptographic applications programming interface (CAPI)
is an API specifically designed to support the introduction of
cryptographic functions into products. It is not necessary to
actually provide the cryptographic functions when the system
is initially sold. Users would then be able to incorporate the
cryptographic add ons of their choice. Technically, a CAPI
would provide an interface to set of cryptographic services;
it would usually include authentication, digital signature
generation, random number generation, and stream or block mode
encryption. Although there are some technical problems
specific to crypto-APIs, most notably those associated with
ensuring the integrity of the security processing, they
exhibit, for the most part, the same advantages as any other
API. That is, there are strong technical and business reasons
for incorporating a crypto-API into open systems.

   CAPIs would enable applications developers to take for
granted the existence of cryptographic functionality and not
have to provide for such functionality themselves. Moreover,
by separating the cryptography from the baseline product,
major system vendors will be able to make changes to the
baseline product driven by market considerations without
waiting for an export license review that would be necessary
for a product with built-in cryptographic functionality.

   Cryptographic APIs are likely to have a profound effect on
the rapidity with which cryptography will diffuse into various
information technology (IT) applieations. If implemented
properly (not a trivial task), they can enhance the security
of stored data and communications. When effective CAPI
technologies are embedded into the operating systems upon
which IT applications build, the result will likely be
encrypted files and communications galore. Operating systems
will be shipped with default eryptographic modules that are
active "out of the box," and users will have the option of
replacing default modules with more capable modules procured
from other vendors.

   The notion of a CAPI is not new. However, in general,
export licenses for products incorporating CAPIs have been
denied, even though such products, with no cryptographic
capabilities built into them, have no cryptographic
functionality and are therefore not specifically included in
Category XIII of the International Traffic in Arms Regulations
(see Appendix L). The reason for such denial has been that
strong cryptographic capabilities could be deployed on a vast
scale if U.S. vendors exported applications supporting a
common CAPI and a foreign vendor marketed (or some party made
available over the Internet) an add-on module with strong
cryptography, which foreign users could then plug into the
baseline U.S. product.

____________________________________________________________

[End Appendix K]




