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
|
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).
|
