#128: section 5 over-claims the properties of an STH
Comment (by [email protected]): Replying to [comment:2 eranm@…]: > If I understand correctly, the point is that the STH is "auditable evidence" only for clients that hold SCTs issued prior to the issuance of that particular STH. > That is, it is not possible a single entity observing the log to verify that the "log kept all its promises" because it may not have all the promises (i.e. SCTs) that the log has made. > > David, is that your point? That's part of my point. The other part is that the single entity may not have all the STHs that the log has made, so the STHs it observes do not necessarily provide any evidence that the log is not returning different views to different observers. Replying to [comment:3 rob.stradling@…]: > Should we qualify the statement then? e.g. something like... > "This provides auditable evidence that the log kept all its observed promises." What do you mean by "observed promises"? > Or could we just remove that entire sentence? That would be a simple way to address this. If you want to keep a similar statement though, you could take a look at https://tools.ietf.org/html /draft-kent-trans-architecture-01#section-3.6 and describe STH generation's role in those 4 checks. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- [email protected] | [email protected] Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/128#comment:4> trans <http://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
