diff options
| author | Linus Nordberg <linus@nordberg.se> | 2014-04-04 13:48:33 +0200 |
|---|---|---|
| committer | Linus Nordberg <linus@nordberg.se> | 2014-04-04 13:48:33 +0200 |
| commit | 1b7423e34b85524696b7a5db2a0491bd4a132169 (patch) | |
| tree | e72f6d916cfae629354d4b26a6154eaaad4502f9 | |
| parent | 6bc8b0b4b767fc60f653b5886fd5879c771eebc5 (diff) | |
moar design
| -rw-r--r-- | doc/design.txt | 30 |
1 files changed, 22 insertions, 8 deletions
diff --git a/doc/design.txt b/doc/design.txt index c4b5f2a..736ba31 100644 --- a/doc/design.txt +++ b/doc/design.txt @@ -4,9 +4,10 @@ This document describes the design of catlfish, an implementation of a Certificate Transparency (RFC6962) log. We have -- a db storing the log (persistently) and replicating r/o copies to n +- persistent storage of x509 certificate chains +- a db storing the hash tree and replicating r/o copies to n secondary nodes -- 1 primary node writing the hash tree to the r/w db +- 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. @@ -14,14 +15,27 @@ Nodes can operate in one of two modes -- primary or secondary. [TODO: A secondary node can become primary. When, how?] Primary nodes -- have write access to the ctlog database (Mnesia?) holding the hash - tree -- store submitted cert chains on disk (DETS?) -- add the stored cert chains to the hash tree and sign the tree - periodically (at least every 30-60 minutes or so) +- 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 +- 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: < 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 |