glenpowell / certificate-transparency

Automatically exported from code.google.com/p/certificate-transparency
0 stars 0 forks source link

Monitor requests consistency proofs that may not always be available (python) #22

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
The python monitor requests consistency proofs for intermediate results. 
The pilot log currently honours these requests, however, a log is not required 
to do so according to the RFC:

"Both tree sizes must be from existing v1 STHs (Signed Tree Heads)."
http://tools.ietf.org/html/rfc6962#section-4.4

Original issue reported on code.google.com by ekasper@google.com on 4 Nov 2013 at 1:01

GoogleCodeExporter commented 9 years ago
If both tree sizes must be from existing STHs, is there any way to find out a 
list of old obsolete STHs? If so, we could amend the code to hop between these 
old STHs. If not, then I'm not sure how we would fix this, short of amending 
the RFC... a monitor *ought* to be able to update itself partially in batches, 
and the RFC should support that.

Original comment by infini...@pwned.gg on 8 Nov 2013 at 12:27

GoogleCodeExporter commented 9 years ago
There's no call for old STHs and I'm not sure how much it would help since 
nothing forbids the log from having a jump of a million certificates.

Amending the RFC to require the log to answer all consistency proof requests 
may inflict additional engineering burden on logs since number of potential 
consistency proofs is quadratic in the size of the tree.

I think we could instead consider adding a get-leaf-hashes API call that would 
return just a range of leaf hashes, rather than leaf inputs. But meanwhile, the 
monitor can still update itself in batches - it just can't mark its state as 
verified before it's downloaded the entire diff.

Original comment by ekasper@google.com on 8 Nov 2013 at 12:54