Cryptography abstraction concept
by Sergei Vyshenski
OpenXPKI as a software product is a collection of building blocks and construction tools meant for deployment of an arbitrary complex and fully functional Public Key Infrastructure (PKI) as specified by the X.509 standard. Of course full functionality is a goal to be reached in versions to come.
From the system point of view, PKI is a special purpose information system for processing, storing and propagation of a certain class of data units: requests, certificates and revocation stuff. At certain stages of the data processing, PKI deals with cryptographic calculations and transformations. But the general structure and workflow of data processing is independent of the employed cryptography.
For the first time in the open source world, OpenXPKI is offering a trustcenter concept which is totally decoupled from the cryptographic details.
Technically, this is achieved by
 providing a cryptographic layer (see Architecture White Paper). It forms a universal cryptographic interface, to which arbitrary (software or hardware) cryptographic backends can be plugged in.
 introducing a cryptographic talking policy: all constituents of PKI in their OpenXPKI realization (ones that are higher than the cryptographic layer) are only allowed to speak to cryptographic tools in a specially designed high level language for cryptographic needs of PKI.
High level language for cryptographic needs of PKI at server side
Our analysis shows that all cryptographic needs of PKI at the server side can be expressed by just the following 19 commands.
 convert_cert

if given a certificate, transform it from PEM into DER or TXT
if given more than one certificates, transform them into a PKCS#7 structure in PEM, DER or TXT  convert_crl
 transform CRL from PEM into DER or TXT
 convert_key
 transform a key from RSA, DSA or PKCS#8 into PEM, DER or PKCS#8
 convert_pkcs10
 transform a request from PEM into DER or TXT
 create_cert
 create selfsigned certificate
 create_key
 create a secret key
 create_pkcs10
 create a certificate request
 create_pkcs12
 store a secret key and related chain of certificates into a PKCS#12 structure
 create_random
 generate a random number
 is_prime
 check if a number is prime
 issue_cert
 issue a certificate which is signed by a Certificate Authority (CA)
 issue_crl
 issue a Certificate Revocation List (CRL)
 list_algorithms
 return list of supported public key algorithms and their parameters
 pkcs7_decrypt
 decrypt data
 pkcs7_encrypt
 encrypt data
 pkcs7_get_chain
 check a chain of certificates, used for signature, and/or encryption/decryption
 pkcs7_sign
 sign data
 pkcs7_verify
 verify signature for data
 symmetric_cipher
 encrypt/decrypt data with one of the algorithms for symmetric encryption
Please note that only one of these commands, namely create_key, obligatoryly requires apriori knowledge of the fact that a certain cryptographic set of tools exists with a specific name (like RSA, DSA, GOST, etc). This apriori knowledge can be acquired with another command: list_algorithms. In interactive scripts you can ask your system to list algorithms and show the list to the user. So that the user can pick up the preferred algorithm with a pointing device. To facilitate automatic processing of this list, severall formats of list presentation is provided. As a result, the highlevel programmer needs no knowledge about which cryptographic backend and which cryptographic algorithms will be available in a really installed system.
All other commands could deduce necessary cryptographic details from the data which they process.
N.B.:
 PKCS#7
 Cryptographic Message Syntax Standard. See RFC 2315. Used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS#10 message). Structure contains data and (possibly) a signature, which signs the data.
 PKCS#8
 PrivateKey Information Syntax Standard. Structure contains encrypted (or not encrypted) secret key.
 PKCS#10
 Certification Request Standard. See RFC 2986. Format of messages sent to a Certification Authority to request certification of a public key. Structure contains a request.
 PKCS#12
 Personal Information Exchange Syntax Standard. Defines a file format commonly used to store private keys with accompanying chain of public key certificates protected with a passwordbased symmetric key.
A list of cryptographic backends recognized by OpenXPKI
Today this list consists of the following entries:
 OpenSSL cryptographic library ver. 0.9.8x with x = a, b, c, d, e.
 OpenSSL0.9.8dgost a clone of OpenSSL cryptographic library with additional support for russian national (GOST) cryptographic algorithms.
Our Cryptography abstraction concept still pays a lot even with that modest choice:
 If one day OpenSSL acquires a new cryptographic algorithm, then it will take a minute to add support of it to the OpenXPKI.
 If one day OpenSSL acquires a support for new hardware security module, then it will take a minute to add support of it to the OpenXPKI.
 If one day we get an alternative to OpenSSL, that is some totally different (software or hardware) cryptographic product, then we have a ready template to fill in to add support of this product to the OpenXPKI.
With cryptographic backend #2 plugged in, OpenXPKI supports both sets of cryptography:
 the same set of algorithms as with cryptographic backend #1, and plus to that:
 russian national cryptographic algorithms GOST. See Working with russian (GOST) cryptography.
This makes OpenXPKI the very first example of an open source trustcenter product which supports two absolutely different sets of cryptography (western and russian) at the same time. So that RSA, DSA, and GOST certificates can coexist in the same working database and move around the same PKI.
Future version OpenSSL0.9.9 is scheduled to link together both cryptographic backends listed above into a single product. It will provide simultaneous and default support of arbitrary cryptographic sets. And OpenXPKI is ready to support this new version of OpenSSL due to the same Cryptography abstraction concept.