Opened 7 years ago

Closed 7 years ago

#96 closed defect (wontfix)

Metadata: Should it be dynamic?

Reported by: eranm@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc: kent@…


Logs could advertise parts of the metadata (for example, the MMD) on a well-known location, sign it and have clients fetch it prior to other requests from the log.
This means certain parameters could change frequently and logs would know exactly how clients should behave when metadata changes.
The downside is that we would have to consider each piece of metadata and the implications of allowing it to change dynamically. For example, if the log is allowed to dynamically change the MMD, what happens to STHs issued "at the seams" ? Does the old MMD apply for them? the new one?

*not* advertising parts of the metadata directly by the logs themselves mean logs have no way of knowing which version of the metadata clients have (as it would depend on external update mechanisms such as browser updates).

A way to prevent this uncertainty is to declare the metadata immutable - i.e. a log roll-over would be necessary to change any of the log's parameters.

Change History (3)

comment:1 follow-up: Changed 7 years ago by benl@…

  • Milestone set to review

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.

comment:2 in reply to: ↑ 1 Changed 7 years ago by rob.stradling@…

Replying to benl@…:

I propose this is resolved as wontfix.


comment:3 Changed 7 years ago by melinda.shore@…

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.