On 25/10/16 11:26, Paul Hadfield wrote:
<snip>
> This may be too late for 6962-bis:
Maybe. Maybe not. Let's discuss it anyway. :-)
I have been thinking about how an
> auditor’s task might be easier if Logs were required to retain their
> historic STHs and provide them on request. It could be done by adding
> an API along the lines of ‘get-sth-at-time’ or ‘get-sths-between-times’.
> (where the first returns the STH with largest timestamp <= the timestamp
> requested, and the second returns a list of STHs with timestamps in
> the range requested).
Alternatively, historic STHs could be looked up by historic tree sizes.
My suggestion...
- add an optional "tree_size" input to get-sth.
- if the "tree_size" input is not specified, get-sth behaves as per
the current specification (i.e., it returns the very latest STH).
- if the "tree_size" input is specified:
- the "sth" output contains the latest STH that existed back when
the tree was that size.
- a "next_tree_size" output is also returned, which an auditor could
then specify as the "tree_size" input to a further get-sth call. (The
auditor would then call get-sth repeatedly until the "next_tree_size"
output is omitted, which would indicate that the very latest STH was
just returned).
> Auditors could then retrieve the full STH history of a log without having
> to have collected them over an extended period of time or having to
> exchange them with other auditors
Indeed. I think this would be a useful feature.
> - although verifying STHs gathered
> by other parties is still worthwhile to detect split views.
Definitely.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
