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.
Steve
On Thu, 23 Jul 2015 at 10:40 Stephen Kent <[email protected]
<mailto:[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] <mailto:[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
