On Fri, Mar 3, 2017 at 2:09 PM, Andrew Ayer <[email protected]> wrote:
> 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. > I could go either way. My preference would probably be to make it OPTIONAL for a log to provide such proofs, because caching. The client can always just fetch the canonical proof and consistency. (Maybe that needs to be a new endpoint.) > > 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)? > The reason you want an indicator in the SCT is so that you know which STH to ask for, e.g., if you're fetching a consistency proof. Otherwise, you have to scan around for the right one. > > - 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. > Thanks for the feedback! --Richard > > Regards, > Andrew >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
