On Fri, 24 Jul 2015 at 16:30 Stephen Kent <[email protected]> wrote: > Ben, > > Based on further discussion during the WG meeting I think all > of the metadata should be described as immutable for a log (instance), > expect for the final STH. That way it will be clear to readers that > if a log wants to change any of these values, a new log MUST be created. >
Agree. (I know! Twice in 24 hours!). > > Steve > > > > > On Thu, 23 Jul 2015 at 10:40 Stephen Kent < <[email protected]>[email protected]> > wrote: > >> There are two types of log metadata. Some if the data is analogous to >> trust anchor >> info and thus distributing it to TLS clients using the same (not >> standardized) browser >> vendor mechanisms makes sense. (This does, though, raise an issue about >> how non-browser >> client acquire this info; Monitors and Auditors are not necessarily >> products of vendors >> and thus there may not be the same infrastructure to distribute this >> sort of data.) >> >> Other log metadata (e.g., MMD and STH frequency) is less like trust >> anchor info and >> it could be distributed by having a signed, time-stamped data structure >> posted at a known >> location associated with the log. > > A potential benefit of this model is >> that a log operator >> can know that if it changes these parameters, all clients are able to >> acquire the new info >> at the same time. If one relies on an unspecified distribution mechanism >> for these parameters, >> a log operator cannot know when all clients have received the new info. >> That uncertainty >> might cause operational problems. So, the title for this issuer is not >> really whether ALL >> metadata should be dynamic, but rather whether some of it should be. >> > > MMD and STH frequency are parameters that cannot be freely varied and > still allow useful operation of the system. It does not seem to me that it > would ever be appropriate to allow logs to unilaterally change them - > that's precisely why they're part of the metadata and not data that can be > retrieved from the log. > > Perhaps the simplest thing to do is note that changing metadata is also > implementation dependent (as well as distribution) and out of scope? > > Obviously if something doesn't belong in metadata at all, that's a > different matter. > > >> Steve >> > #96: Metadata: Should it be dynamic? >> > >> > Changes (by [email protected]): >> > >> > * milestone: => review >> > >> > >> > Comment: >> > >> > We've already discussed this, I feel sure, and the general point is >> that >> > allowing logs to manipulate their own metadata is dangerous, as you >> state. >> > That's why the I-D says its distribution is out of scope. >> > >> > As you know, in practice, Chrome defines its own log metadata, and >> that is >> > what clients use. I imagine this will be the general pattern. >> > >> > I propose this is resolved as wontfix. >> > >> >> >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
