diff options
author | Linus Nordberg <linus@nordberg.se> | 2014-05-03 10:54:55 +0200 |
---|---|---|
committer | Linus Nordberg <linus@nordberg.se> | 2014-05-03 10:54:55 +0200 |
commit | 68f6bdf0f88322867b35a6ae35a0c4c3ea641884 (patch) | |
tree | e11fbf5a349086bbed407f2020219a5d5c679820 /doc/design.txt | |
parent | 7725f46cd64c5a405ffed6177019383ffe18dd8e (diff) |
Rename to ctls.
Diffstat (limited to 'doc/design.txt')
-rw-r--r-- | doc/design.txt | 49 |
1 files changed, 29 insertions, 20 deletions
diff --git a/doc/design.txt b/doc/design.txt index ba28fdc..a83ec85 100644 --- a/doc/design.txt +++ b/doc/design.txt @@ -1,36 +1,45 @@ -catlfish design (in Emacs -*- org -*- mode) +ctls design (in Emacs -*- org -*- mode) -This document describes the design of catlfish, an implementation of a -Certificate Transparency (RFC6962) log. +This document describes the design of ctls, an implementation of a +Certificate Transparency (RFC6962) log server. 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 +- "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. +?Nodes can operate in one of two modes -- primary or secondary. [TODO: A secondary node can become primary. When, how?] -Primary nodes +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 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?) +- 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?] -Secondary nodes -- have read access to the ctlog 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 -- [size] - -The log data -- is persistently stored in a file system on disk -- grows with 5 GB per year, based on 5,000 3 kB submissions per day Scaling, performance, estimates - submissions: less than 0.1 qps, based on 5,000 submissions per day |