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