Opened 8 years ago

Closed 7 years ago

#24 closed enhancement (fixed)

Add a section about log metadata

Reported by: eranm@… Owned by: eranm@…
Priority: minor Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

Such a section should describe what is considered a log's metadata, which should include:

  • URL (including whether it operates over HTTP, HTTPS or both)
  • Public key
  • Maximum Merge Delay
  • Its operator
  • Hash algorithm used in the tree.

I expect we would not care where the log's metadata comes from and not specify how to obtain it.

Change History (6)

comment:1 Changed 7 years ago by eranm@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…

From the discussion in the trans wg meeting:

  • Several voices in favour of specifying not just what the metadata is, but an exact format for it and a method for getting it from logs (i.e. another API call).
  • Few voices in favour of specifying a method of feeding said metadata to clients. Noted that it may ignored by implementors and presents the chicken-and-egg problem (how to securely transmit the metadata from log to client?).

My understanding of the consensus is:
Strong opinion in favour of specifying the metadata format and method for getting it from logs (because it's essential for implementation and such a mechanism is needed anyway).

Based on that, I'll propose (in this ticket) a JSON format for the log's metadata (as well as an additional API call) based on the JSON format here:
http://www.certificate-transparency.org/known-logs/log_list.json

comment:2 Changed 7 years ago by eranm@…

(raw extract from trans meeting minutes at IETF 90)
Steve Kent: There needs to be a standardized way of doing it.
Ben Laurie: Clients trusting logs is like clients trusting CAs. Different clients will have different criteria for which logs to trust.
SK: actually talking about the metadata, contents
paul HOffman: completely disagree with Steve, it is fine that there must be one way that a log server must provide it. A client should not be forced to get it in a particular way
Should be nothing about how clients must be able to get it.
PHB: interop is not the only reason to put something in a spec.
Wes Hardaker: leveling up... work isn't complete, needs much more specification.
Leif : not worried about full specification, syntax is what we need to be worried about.
SK:
BL: If you allow the log to specify its own
Eran: Agree with Leif and Stephen, specify a format for the metadata. Can't specify how the clients get the metadata.
Melinda Shore: sensing agreement to specify a mandatory metadata format for the log servers.

comment:3 Changed 7 years ago by eranm@…

MMD should be included in the metadata.
Ben also suggested: which browsers is the log included in, start date, whether the log has been turned down or not.

comment:4 Changed 7 years ago by benl@…

  • Priority changed from major to minor
  • Type changed from defect to enhancement

Partially closed by https://github.com/google/certificate-transparency-rfcs/commit/b750e18e45eed3405cb6c956d09a48b2ae48bb4f.

As I said at IETF 90 (transcript is incomplete), allowing a log to define its own metadata is obviously a security hole, so it is not clear to me what the value of defining an API for the metadata is.

comment:5 Changed 7 years ago by benl@…

  • Milestone set to review

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

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