Packaging Cryptographic Provider Applications and Modules

In the Solaris operating system, application software is delivered in units that are
called packages. A package is a collection of files that are required
for the distribution and installation of a software product. Packages are usually designed and
built by the application developer after the development of the application code is
complete. For general information about packaging software applications, see Application Packaging Developer’s Guide.

Packaging a cryptographic provider has two additional requirements:

The developer must supply input files that add the application to the configuration files that manage the cryptographic framework.

The developer must supply an X.509 certificate to indicate compliance with the United States government's export laws. For testing purposes, the certificate can be generated prior to obtaining U.S. government approval. A package must have approval and a signed provider to be shipped.

Complying with U.S. Government Export Laws

The United States government restricts the export of open cryptographic interfaces, which are
also referred to as crypto-with-a-hole. Due to this restriction, all vendors of
providers must obtain export approval from the U.S. government. The vendor needs to
request a certificate from Sun Microsystems, Inc. to indicate compliance with export laws.
The vendor then signs the provider electronically and ships the software with the
certificate.

In the export approval process, the strength of your encryption determines the countries
in which the software can be used. The U.S. government defines two export
categories for encryption products that are manufactured in the U.S.A.:

Retail encryption products – Retail encryption products are permitted to be shipped to all countries except for designated nations that are considered to be security threats.

Non-retail encryption products – Non-retail encryption products are permitted for domestic use only and to countries that have been exempted by the U.S. government.

If your provider has non-retail approval, you can make the provider eligible for
retail approval. Retail approval can be obtained by disabling the use of your
provider by certain callers such as IPsec. Sun provides two different certificates in
this case, for restricted and unrestricted use. You indicate this situation in the
certificate request process, To Request a Certificate for Signing a Provider. In addition, a special activation file must be generated,
signed, and shipped with the provider. See To Generate an Activation File for Retail Export.

Packaging User-Level Provider Applications

A third-party developer of a user-level cryptographic provider application completes the following process:

Ship the certificate with the package. The certificate must be placed in the /etc/crypto/certs directory.

Add the pkcs11conf class into the CLASSES string of the pkginfo file. The following line should be added:

CLASS=none pkcs11conf

Create an input file pkcs11.conf in the etc/crypto directory.

The input file for user-level providers is named pkcs11.conf. This file specifies the path to the provider. The pkcs11.conf uses the following syntax for the entry:

filename

The entry is an absolute path to a file such as /opt/lib/$ISA/myProviderApp.so. This file is added to the configuration file when pkgadd is run. Note the $ISA expression in the path name. $ISA points to either a 32-bit version or a 64-bit version of the application, as needed.

Add the following line to the package's prototype file:

e pkcs11conf etc/crypto/pkcs11conf 0644 root sys

Packaging Kernel-Level Provider Modules

A third-party developer of a kernel-level cryptographic provider module completes the following process: