#128: section 5 over-claims the properties of an STH
Comment (by [email protected]): Replying to [comment:4 david@…]: > 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"? I mean the SCTs that have been observed by an auditor that is auditing the "auditable evidence". But I concede that "all...observed" is unclear. It could be taken to mean all SCTs that have been observed by anyone (rather than all SCTs observed by one particular auditor). > > Or could we just remove that entire sentence? > > That would be a simple way to address this. I've proposed that change here: https://github.com/google/certificate-transparency-rfcs/pull/98 > 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. I think that that level of detail of the auditing function would be out of place in a section that is intended to introduce log requirements. -- -------------------------+------------------------------------------------- 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: <https://trac.tools.ietf.org/wg/trans/trac/ticket/128#comment:5> trans <https://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
