PKI and Key Management
By wyllys on Jan 25, 2007
If you have ever written (or debugged) an application that works with PKI objects (X.509 certs, public key technologies, etc), you may have noticed that there is no "standard" interface or tools for managing this stuff. Even worse, there is precious little in the public domain for enforcing any kind of policy on the use of those objects. The Key Management Framework project is our attempt to fill in some voids in the world of PKI programming and management.
Traditionally, programmers have chosen OpenSSL or NSS to provide their certificate services. Both are sufficient, but each suffers from some limitations and some drawbacks. For OpenSSL, there is no concept of a "database" of certificates, it pretty much just uses flat files and directories to store the certs and keys. Additionally, there is no overriding policy control mechanisms available from the library itself. NSS is a little more advanced in that it does support a database, it supports PKCS#11 tokens, and it has a primitive concept of policy (via trust flags, etc). The Solaris Cryptographic Framework introduced a proper PKCS#11 programming interface for Solaris 10 and later, but it lacks policy controls and alot of convenience functions needed to easily manipulate and handle certificates.
KMF attempts to bridge the gaps and add value by providing a new set of interfaces that sits above each of the above systems and allows programmers to write to a unified API and be able to access certs and keys in any of the above keystores. Additionally, by using the KMF progamming interfaces, the application can take advantage of the new KMF policy enforcement system which will allow an application to restrict the usage of certificates based on attributes such as the key usage fields (both KU and EKU) and specify a validation method such as OSCP or CRL checking. All of this is regardless to the location or storage of the actual keys. The application can still read and write certificates and keys from an NSS database (for example) using the KMF APIs, but by using KMF you get the additional advantages of the policy system and the ability to use some new convenience functions for parsing and manipulating the certificates.
Additionally, KMF introduced a whole set of new features to the pktool utility. pktool(1) can now be used to do things like create self-signed certificates, create certificate signing requests (to send to a CA for signing), import/export/delete/list certificates and keys in ALL of the supported keystores (OpenSSL files, NSS databases, and PKCS#11 tokens). This is a single tool (supported and integrated in the OS) that allows administrators to manage certificates regardless of their actual keystore.
If you think this is valuable or interesting and want to read more, come visit the KMF OpenSolaris area and read our documents and join in the discussions (or start a new one). We are looking for feedback.