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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
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 primary database storing x509 certificate chains [replicating r/o
copies to a number of frontend nodes?]
- a hash tree kept in RAM
- one secondary database per frontend node, storing the most recently
submitted data
- a cluster of backend nodes with an elected leader which periodically
updates the primary db with data from the secondary db's
- a number of frontend nodes accepting http requests, updating
secondary db's and reading from [local r/o copy of?] the primary db
Backend nodes
- are either asleep, functioning as storage only
or
- store submitted cert chains in persistent media
- have write access to the primary database holding cert chains
- periodically append new cert chains to the hash tree and sign the
tree head
Frontend nodes
- reply to the http requests specified in RFC 6962
- write submitted cert chains to their own, single master, secondary
database
- have read access to [a local copy of?] the primary database
The primary database
- stores cert chains and their corresponding SCT's
- is indexed on a running integer (primary) and a hash of the cert
chain (secondary)
- runs on backend nodes
- is persistently stored on disk on several other backend nodes in
separate data centers
- 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 secondary databases
- store cert chains, unordered, between hash tree generation
- run on frontend nodes
- are persistently stored on disk on several other frontend nodes
- are typically kept in RAM too
- max size is around 128 MB, based on 10 (3 kB) submissions per second
for an hour
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). We could start at 4h which would give us some
time to sort things out in case of trouble.
|
