ctls design (in Emacs -*- org -*- mode)

This document describes the design of ctls, an implementation of a
Certificate Transparency (RFC6962) log server.

We have
- "a db" storing 
  i) x509 certificate chains and 
  ii) the hash tree,
  replicating r/o copies to n secondary nodes
-? 1 primary node updating the db
-? n secondary nodes reading from local r/o db

Nodes reply to the https requests specified in RFC 6962.
?Nodes can operate in one of two modes -- primary or secondary.
[TODO: A secondary node can become primary. When, how?]

Node roles
- depot
- tree-maker
- tree-signer
- submission-point
- query-replyer

?Primary nodes
- store submitted cert chains in persistent media
- have write access to the database holding cert chains and the hash tree
- periodically add cert chains to the hash tree and sign the tree head
  (like ever 10 minutes and at least every hour?)

?Secondary nodes
- have read access to the database [which is pushed or pulled?]

The log data db
- is persistently stored on [more than one] disk [files, DETS, mnesia,
  some other database?]
- grows with 5 GB per year, based on 5,000 3 kB submissions per day
- max size is 300 GB, based on 100e6 certificates

The hash tree db
-? is persistantly stored on disk
-? is implemented as a 'protected, ram_file' DETS table

Scaling, performance, estimates
- submissions: less than 0.1 qps, based on 5,000 submissions per day
- monitors: 6 qps, based on 100 monitors
- auditors: 8,000 qps, based on 2.5e9 browsers visiting 100 sites
  (with a 1y certificate) per month (assuming a single combined
  request for doing get-sth + get-sth-consistency + get-proof-by-hash)

Open questions
- What's a good MMD? Google seem to use an MMD of well over 1h at the
  moment (early 2014).