On Fri, 3 Mar 2017 13:24:51 -0500 Richard Barnes <[email protected]> wrote:
> # STH Discipline > > Either style of auditing also works better if logs have a notion of > "STH discipline", in the following sense: > > 1. The official state of the log comprises a sequence of STHs issued > at specified intervals. > > 2. For each certificate in the log, there is a single "canonical STH" > to which > the log will produce an inclusion proof. To be clear, would there still be a way to get inclusion proofs to non-canonical STHs? Clients wouldn't have to use them if they didn't want to. > Proofs to other STHs are > done by > adding a consistency proof to the inclusion proof. > > This property makes things work more smoothly in both auditing models: > > - If the browser is willing to cache STHs, this tells the browser > exactly which > STHs it needs to cache in order to validate all inclusion proofs. > > - Everything is more cacheable, since there's only one inclusion > proof per certificate, and a limited set of heads among which > consistency needs to be > calculated. > > - Cacheability means that the fetches of inclusion proofs get greater > privacy > benefit from caching, since they depend only on the certificate, > not the STH > that the client is using. Likewise for consistency proofs, because > of the reduced variety. > > >From a protocol point of view, I haven't done a thorough evaluation > >of the > document, but there are at least a few things you would want to make > this model > work: > > - Prose that articulates the above bounds on logs / inclusion > proofs / STHs. Probably a notion of "STH issuance frequency" parallel > to MMD. > > - A field in an SCT that indicates the canonical STH for the > certificate in question. Possibly a serial number in STH that SCTs > could refer to. Is this necessary? Why not define the canonical STH as the first STH issued after the SCT (based on timestamp)? > - An API endpoint for fetching STHs in the official sequence (in > addition to the current one, which is the only option right now). +1. I think any privacy-preserving auditing mechanism will need such an endpoint so that STHs can be reliably distributed to clients. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
