summaryrefslogtreecommitdiff
path: root/doc/design.txt
blob: 1562d1bf85bb01826b507a5c83eb7ae20a89535f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
catlfish design (in Emacs -*- org -*- mode)

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

We have
- persistent storage of x509 certificate chains
- a db storing the hash tree  and replicating r/o copies to n
  secondary nodes
- 1 primary node updating the hash tree in the r/w 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?]

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

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

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

The log data
- is persistently stored in a file system on disk

Scaling, performance, estimates
- submissions: less than 0.1 qps, based on 5000 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).