On 25/10/16 13:57, Kurt Roeckx wrote: > On Tue, Oct 25, 2016 at 01:30:08PM +0100, Rob Stradling wrote: >> 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... > > You can get multiple signatures for the same tree size / hash > currently. Do you want the first. the last, or some random STH in > that case?
Ah, good point. "In general, there is no need to produce a new STH unless there are new entries in the log; however, in the unlikely event that it receives no new submissions during an MMD period, the log SHALL sign the same Merkle Tree Hash with a fresh timestamp. Please execute "s/tree_size/timestamp/" on my previous post (which makes it functionally equivalent to Paul's get-sth-at-time proposal, except that my proposal merges that API into get-sth). <snip> -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
