On Fri, Mar 3, 2017 at 5:19 AM, Al Cutter <[email protected]> wrote: > I thought I'd throw a few things into the discussion... > > So, I think what Richard, Nick and Zakir have reinvented, is more or less > the original plan for how CT was going to work; chains would be submitted, > and the caller would be told either a) here's your inclusion proof+STH, or > b) come back and try again in a bit. > At that time, CAs were understandably wary of blocking their issuance on > processes with an unbounded (or at least slightly hand-wavy) deadline. > Enter SCTs, which we we all know and, um, love. > (You all probably knew that already, and if you've been following or > involved with CT for a while also probably know a lot of the trade-offs > that we made in our Google log implementation, mostly swapping speed and > comfort for quite paranoid levels of redundancy.) >
Is it possible to "let the market decide" whether STHs can be served in a reasonable timeframe so we have a chance to figure this out in practice? For example, what if browsers with a CT policy allowed either SCTs *or* STHs to qualify? Logs could optionally offer endpoints that produce STHs immediately upon logging (in addition to their SCT endpoints), and CAs could see whether logs can produce STHs at levels of latency and reliability acceptable to production use. -- Eric
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
