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.
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
