Keyserver network synchronization is one of the more technically challenging aspects of keyservers design and deployment. In the current version of the CryptNET keyserver, great effort has not been made to solve this problem in an optimum way. This version of the keyserver simply uses sockets as it's preferred mechanism of synchronization. Basically, the keyserver packets includes a program which mimics a client submitting a key.
In future versions of CKS, an optimal solution will be persued. Most likely, a binary synchronization protocol will be developed to allow rapid synchronization with other hosts.
cks_sync
This is the primary program responsible for synchronization. This program is meant to be run from a cron job. I currently have the program set up to run nightly, however it may be practical to run the program hourly. cks_sync queries the postgres server in order to build a linked list of servers to synchronize with, and a list of public keys which need to be synchronized. cks_sync then walks the lists of servers and keys transmitting the keys to instances of cksd using the hkp protocol (http 1.0 cgi post).
Keys which are to be synchronized are stored in the cks_pending_sync
table by their fingerprint. The list of servers to synchronize with
is stored in the cks_other_servers table. The field
sync_priority allows a priority to be set for each server. When
cks_sync pulls the server list, it sorts the results by the priority
field.
cks_sync_manage
cks_sync_manage is a self explanatory program used to manage the
records in the cks_other_servers table.
cks_mail_sync
cks_mail_sync is a special program which was written to allow the CryptNET Keyserver Network to be synchronized as a client on a pks based keyserver network. pks based networks use email to synchronize. The pks package contains pop3 client code which pops keys off a mail box after a set period of time has elapsed and add them to its keyring. This design requires that a pop3 daemon is run and that a pop3 account password is stored in the pks config files. In the interest of security, cks_mail_sync was designed in a different manner.
cks_mail_sync is meant to be called by your MTA through the addition of an entry in a .forward file. After authorization is added for the mail account (usually called pgp-keys) in the postgres database, cks_mail_sync can be called by the MTA when an email arrives from a pks server. cks_mail_sync is designed to parse and process the key. If the key is not currently in the database, cks_mail_sync will add it. cks_mail_sync will also handle key material mergers as required.
The current plan for the CryptNET Keyserver Network is to run
cks_mail_sync only on the primary node - gnv.us.ks.cryptnet.net -
and then to have gnv.us.ks.cryptnet.net synchronized keys from
pks based servers to other CryptNET Keyserver Network nodes with
the CKS cks_sync hkp based synchronization. cks_mail_sync is
provided in the distribution for instructional purposes and in the
event that anyone wishes to set up a CKS based keyserver independent
of the CryptNET network.
cksd
cksd is the main daemon responsible for keyservice. The only role that cksd plays in synchronization is through the reception and storage of key transmissions from cks_sync.
CKS is a novel keyserver platform in that it allows keys to be specified as rejected. A rejected key cannot be added to the database. Keys can only be given rejected status by the keyserver node administrator through the delete.cgi program. The mechanism of action behind this is the storage of the rejected key's fingerprint is a database table called cks_rejected_keys. If a synchronization addition of a rejected key is attempted, the key will not be added to the database.
CKS is currently not capable of synchronizing key rejection status across different keyserver nodes due to the authentication and security requirements of such a mechanism. This feature will likely be available in the near future (post 1.0.0) as this is not a terribly difficult problem.