Table of Contents
After version 0.9.2 the OpenCA core team decided to only support SQL databases because we need several features of SQL. Such aspects include functional requirements and performance issues. The result was a major change in the database backend because now all parts of the code can use such nice things like wildcards. We will discuss now the most important parts of the database design.
There are three major technologies which OpenCA needs:
Tables
Sequences
Indexes
Now let's start explaining all three issues.
The first technology is the most complex one. We have to handle two classes of tables - one for objects and one for hashes. OpenCA starts with using tables only to store objects. The interface was completely object oriented. It was only possible to handle cryptographic objects with the database backend (e.g. CRLs, CSRs, CRRs, certificates and CA certificates). Such an object will be stored as follows in the database:
This is the serial number of the object.
This is the serialized object.
This field describes the format of the serialized object.
The other columns of the database tables are reserved for the searchable attributes. OpenCA's database backend includes a specification for which stuff you can search in the object tables.
Hashes are handled a little bit different. You give the database backend a hash reference and you get a hash reference from the database backend. Such tables are used for content which is not object based. The following tables are hash based:
This table is used to store any private data like keybackups, private keys and PINs. It only has three columns private_key, data and format where format is the type of the stored data.
The statemachine has an own table to store all states of the active batch workflows. This is needed for performance reasons. If we would store the states of the statemachine in the data table then we have a big performance problem even if we use indexes. Otherwise it is easy with such a table to monitor active batch processors and to implement an error handling and escalation mechanism.
The table was originally developed to hold the data of the batch system but it can be used to store any other data too. The table has two keys a primary one and something like a global ID. The global ID is used to identify data from the same usecase. You can search on the table for one global key and you get all rows which contain data of this context. This is today usually a batch workflow but it can be an isolated key backup or a user set of two private keys one for signing and one for encryption in the future.
The other columns are content type, array counter, number and string. The real names of the columns are of course different to avoid conflicts with the different SQL dialects. The design allows by this way the implementation of dynamic content detection and array support. More details about the usage of this table you can found at Chapter 18, Batch System.
Document generated: 2005-08-05T17:53+0200