1. Oracle Solaris Security for Developers (Overview)
2. Developing Privileged Applications
3. Writing PAM Applications and Services
4. Writing Applications That Use GSS-API
7. Writing Applications That Use SASL
8. Introduction to the Oracle Solaris Cryptographic Framework
9. Writing User-Level Cryptographic Applications and Providers
10. Using the Smart Card Framework
A. Sample C-Based GSS-API Programs
D. Source Code for SASL Example
F. Packaging and Signing Cryptographic Providers
Packaging Cryptographic Provider Applications and Modules
Complying with U.S. Government Export Laws
Packaging User-Level Provider Applications
Packaging Kernel-Level Provider Modules
Adding Signatures to Providers
To Verify That a Provider Is Signed
Typically, the developer of a provider requests the certificate. However, the system administrator might be called on to handle the request as part of a site's security policy.
The command generates a private key along with the certificate request.
% elfsign request -k private-keyfile -r certificate-request
Path to the location of the private key. This key is needed later when the system administrator signs providers for the Solaris cryptographic framework. The directory should be secure. Use a different directory from the directory that holds the Sun certificate.
Path to the certificate request.
The following example shows how a typical request is submitted to Sun:
% elfsign request \ -k /securecrypt/private/MyCompany.private.key \ -r /reqcrypt/MyCompany.certrequest Enter Company Name / Stock Symbol or some other globally unique identifier. This will be the prefix of the Certificate DN:MYCORP The government of the United States of America restricts the export of "open cryptographic interfaces", also known as "crypto-with-a-hole". Due to this restriction, all providers for the Solaris cryptographic framework must be signed, regardless of the country of origin. The terms "retail" and "non-retail" refer to export classifications for products manufactured in the USA. These terms define the portion of the world where the product may be shipped. Roughly speaking, "retail" is worldwide (minus certain excluded nations) and "non-retail" is domestic only (plus some highly favored nations). If your provider is subject to USA export control, then you must obtain an export approval (classification) from the government of the USA before exporting your provider. It is critical that you specify the obtained (or expected, when used during development) classification to the following questions so that your provider will be appropriately signed. Do you have retail export approval for use without restrictions based on the caller (for example, IPsec)? [Yes/No] N If you have non-retail export approval for unrestricted use of your provider by callers, are you also planning to receive retail approval restricting which export sensitive callers (for example, IPsec) may use your provider? [Y/N] Y
The private key is placed in the file name that you specify, for example, /etc/crypto/private/MyCompany.private.key file. The certificate request is also placed in a file name that you specify, for example, /reqcrypt/MyCompany.certrequest file.
Send the certificate request to the following email address: solaris-crypto-req@sun.com
Sun generates a certificate from your certificate request file. A copy of the certificate is sent back to you.
For security, the private key and the certificate request should be stored in other directories.