Add a section about log metadata

[eranm@…]

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.

[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

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

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

[benl@…]

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.